On Mon, 09 Jan 2006 14:29:06 -0000, Rocky Burt <[EMAIL PROTECTED]> 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.



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to