[Zope-CMF] Re: The components of Archetypes

[whit]

thanks for starting up this conversation Rocky!

I think these assertions are more or less deadon.  The next step is 
charting a path for transition.  for CMF, zope3 / five provides 
lighterweight analogs of AT features.  What is currently lacking is a 
mapping layer to allow AT users to use the zope3 analog in a meaningful 
way within AT.

As I've stated before, I think the process here is similar to how five 
gradually and systematically replaced functionality in zope2. 
Maintaining multiple content frameworks for CMF, z3 and AT is a waste of 
community effort, and I would like to see AT move toward being more of a 
glue library for components available to all.


> #1: Personally I believe there is too much boilerplate code required in
> building plain CMF types.  This is the primary reason I find it
> convenient to use Archetypes, because a lot of that boilerplate code
> isnt' necessary.  Its my opinion that CMF be refactored a bit to
> minimize this boilerplate in a similar fashion as to Archetypes has done
> it (which means Archetypes would no longer be any more convenient to
> build a type in).  Bottom line: lets make CMF easier and more convenient
> to use

z3 does a good job of reducing some of this boilderplate: it gives us 
dublin core and annotations.  For obvious reason, it doesn't help much 
with factory type information.  CMF is scheduled to move away from fti 
iirc, but some sort of localized "site" configuration of 'content types'
is a basic requirement of any progeny of CMF.

> 
> #2: Archetypes schema support has long provided plone developers with a
> way of defining (in a sensible style) the fields and types of fields
> created on a content type class.  Personally I believe the automatic
> creation of mutators/accessors to be a negative thing, mentioning that
> explicit is always better than implicit. 

I think z3 schema's use of an interface to define accessors and mutators 
looks pretty good.

  But regardless, Zope 3 is
> providing similar support for all persistent objects.  And since moving
> to Zope 3 development techniques is a strong goal of plone and cmf
> development, why not just build on top of that rather than continuing
> with our own AT based schema notion?  Alec has the right idea here with
> his plone_schemas product.  Bottom line: lets start working with Zope 3
> schema's

The issue is how to get there without maiming our developers(not an 
insurmountable problem, just something that needs to be faced).  Some 
basic decoupling of the AT schema from the AT content object and 
decoupling of the different facets of the schema(View, Marshalling, 
Storage, Model, etc) are necessary to get there.

here is a rough list of steps I see to move toward convergence:

1. return schema and schemata by interface rather than attribute access

2. make at wigets, fields, and validation interchangeable with z3 
widgets and fields

3. start deprecating features that impede convergence: auto-generated 
mutators and accessors, etc

4. deprecate widgets, storage, marshalling, etc in the schema.  Move the 
declaration of this behavior elsewhere.

The AT schema is really a system for configuration and we should treat 
it like that, whether it be treating old schemas inclusion of view data 
and storage as default options, or moving schema operations to paradigms 
configurable by zcml.

> 
> #3: Widgets is one area where development outside Archetypes has
> flourished.  There has been a plethora of third-party widgets developed
> that people reuse.  Zope 3 also has a widget mechanism and following the
> thought as in #2 ultimately this is the direction we're moving in.  The
> problem of course at the moment is that Archetypes widget library is
> quite a bit more diverse than zope 3's widget library so there would
> definitely need to be some work porting the widgets from AT to zope 3
> (plone_schemas also lets you use z3 widgets today).  Bottom line: lets
> start migrating AT widgets to Zope 3 and use existing Zope 3 widgets today

see above

> #4: There has been many a discussion regarding this item.  Most people
> talk about separating out the references engine from Archetypes into its
> own product.  As a primary goal this should allow any CMF based content
> type to participate in the references logic and not just ones built on
> Archetypes.  Bottom line: lets move the references engine out of AT and
> into its own product

I think this is a prime target and if people are interested in tackling 
this, I would like to work on it at the snow sprint.

see next email ->>


> So what do you all think?
> 
> In the CMF community, I know some (all?) of the CMF purists think
> Archetypes is generally unnecessary and adds a lot of bloat based on
> feedback I've received.

AT is pretty unkempt compared to the likes of CMF or z3 and subject to 
the looser faster style of plone programmers.  Breaking AT down into 
reusable components may improve adoption, since using some of AT wont 
necessarily mean you have to use the whole of AT; it will also force 
improvement in orthogonality and testability.

We also need a general change in attitude towards AT.  Yes it sucks in a 
lot places, yes it is delicate, but we the plone community are stuck 
with it.

> In the Plone and Archetypes communities I know using Zope 3 techniques
> in development is a hot topic and so seeing Archetypes move to a more
> zope3-based architecture would be a great thing.

1.) even Chris Withers has to deal with AT.  Lets give him less reasons 
to complain.  can we start charting a roadmap right now? Ben conducted a 
survey earlier in the year.  we should continue this process and start 
laying out some concrete goals.  We can start unravelling these at the 
snowsprint.

2.) this has to be gradual and sensitive to back compatibility. As an 
approach, I think we should view the z3 architecture less as an end but 
a means for unfucking AT.  Letting the past coexist with the future 
without having to suffer grueling migrations would be nice too.


-w