The components of Archetypes

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


Here are my thoughts on the direction of those components:

#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

#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.  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
schema's

#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

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.

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.


Regards,
Rocky


-- 
Rocky Burt
ServerZen Software -- http://www.serverzen.com
ServerZen Hosting -- http://www.serverzenhosting.net
News About The Server -- http://www.serverzen.net



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click