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
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
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
#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
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
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.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests