[Zope-CMF] Re: The components of Archetypes

[Martin Aspeli]

On Mon, 09 Jan 2006 14:29:06 -0000, Rocky Burt  
<rocky at serverzen.com> wrote:

> Hi all,
>
> Sorry about the cross post, but I thought this topic concerned CMF,
> Plone, and Archetypes equally.
>
> I had a discussion with Alec Mitchell recently where we talked about the
> components that made up Archetypes and what people have talked about
> regarding these components.
>
>   1) Ease of development - AT helps cut down on boilerplate code
>      as compared to building a regular CMF type (without AT)
>
>   2) Schema - The ability to declare which fields a content type has
>      and what "types" those fields are
>
>   3) Widgets - The ability to declare general purpose distributable
>      widgets that get displayed by default for either viewing a field
>      directly or viewed the editable version of a field
>
>   4) References - Being able to have a common framework that allows us
>      to relate one AT-based content type instance to another

Having just read Philipp's excellent book, I too would like to get more  
into Zope 3-style development. However, my feeling is that trying to  
provide a compatability layer is not necessarily necessary (heh). I am  
only thinking out loud here, so you may yet prove me wrong. :)

Archetypes is fairly lightweight, actually (do I hear chuckles?), from the  
developer perspective. Making an AT schema is a fairly mechanical process  
(cut-and-paste, macros in your editor, ArchGenXML) - it's very  
declarative. Taking my AT schema and making a Z3 schema for it would be  
trivial so long as Z3 schemas supported everything I needed.

Then there's AT support machinery, like vocabularies and validators.  
Again, these are fairly self-contained and easy to port to a Zope 3 story.

For the UI, we have page templates that could be ported to views, and  
actions and aliases that would probably be mvoed from dicts and lists to  
ZCML. Again, this is very declarative.

Then, I may have all kinds of logic, either with custom  
mutators/accessors, or with methods on my class. Factoring that out into  
adapters is again not rocket science.

My point is that for the end-user, the base use case for Archetypes is  
pretty simple. If you had the time, you could write a script that read an  
AT product and spat out a Z3 one (in theory, I know it's harder than  
that). Where things get complex is where people do crazier things - custom  
storages, rummagings with AT's internals.

So I see two options:

  1. Try to evolve Archetypes from the current model into a more modern Z3  
one.

  2. Try to document how to do things people are used to do with Archetypes  
with Z3, cataloging patterns and best-practice, and at the same time  
factor things out of Archetypes that are missing in the pure Z3 world in  
such a way that they may be usable there.

I'm leaning heavily towards 2. The current 1.x series of Archetypes has a  
long shelf life still, there's LOADS of code out there depending on it,  
including Plone's ATContentTypes. I think that trying to do a  
compatability layer to a complex and less-than-perfectly documented piece  
of software *and* move to a completely different design metaphor is rather  
ambitious. As a product developer, I'd probably rather gradually migrate  
my projects to a new metaphor when I'm ready than be forced to do so by  
the framework (upgrade and yipes, it's all changed!). And I'd rather not  
trust a compatability/migration layer that only covers 80% of the cases.  
So I'd take some pain in rewriting some old products as and when it makes  
sense.

For that to happen, there are three things we need:

  1. Binary/ZODB compatability or migrations that are easy to work with.  
Make it easy for me to switch my AttributeStorage or AnnotationStorage or  
whatever else types to use Z3 schemas' storage. (Note that I'm trying to  
work on this story now with contentmigration and a "port" of the Z3  
zope.app.generations framework to make sense for CMF sites; of course  
GenericSetup also plays a part here).

  2. A suite of components that make the Z3 story as powerful and  
featureful as Archetypes, such as a reference engine, a storage  
abstraction mechanism, a powerful validation mechanism, etc. This must be  
well-integrated and well-tested. In short, we need someone to champion  
this, to own it, and to manage what goes in and what isn't good enough.  
Without process, we're likely to repeat the mistakes of Archetypes.

  3. DOCUMENTATION! We need to be much, much better than Archetypes was, at  
explaining the model, at explaining the API, at demonstrating best  
practice and at providing examples. Without it, no-one will make the  
switch and the effort will never manage to stay afloat.

Martin

-- 
(muted)