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

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.


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to