[Zope-CMF] Re: The components of Archetypes
Martin Aspeli
optilude at gmx.net
Mon Jan 9 18:52:34 EST 2006
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)
More information about the Zope-CMF
mailing list