[Framework-Team] Re: Our attititude to Archetypes

Martin Aspeli optilude at gmx.net
Tue Apr 11 19:12:39 UTC 2006

On Tue, 11 Apr 2006 19:07:03 +0100, Rob Miller  
<ra at burningman.com> wrote:

> Martin Aspeli wrote:
>> In a way it feels unclean and a bit dangerous if our goal is to lighten  
>> up or even move away from Archetypes. However, it's also a good thing.  
>> AT is an insulation layer. It's ubiquitous and unifies the API to  
>> content types.
> for a while i was keen on the idea of replacing AT, componentizing it  
> out until there wasn't any there there, eventually replacing the  
> components with other pieces.
> i'm still not against that idea, but i've recently come back around to  
> the possibility that AT might be salvageable.  if it gets broken up into  
> little bits, and the worst stuff is made better, then we may just find  
> ourselves with something that is not so bad to work with, w/o feeling so  
> strong a need to have to make it die completely.

If you look at the thread I started on at-dev (and please respond to it if  
you have ideas) for re-using content types and making schemas more  
flexible, my conclusion is similar.

Logic etc. should be made into adapters. View logic should be made into  

CMF requires a pile of boilerplate, and I'm happier to let AT handle that  
than to replicate it myself. When CMF starts being able to use adapters  
for this stuff, AT can adapterise itself into pieces.

The schema is there for base_edit and to generate accessors, basically.  
One thing I thought about was to have some mechanism for making AT  
accessors turn into python 2.4 properties, so that we could make a  
zope3-looking schema that used properties but have AT create the magic.  
AttributeStorage makes that a bit hard, though.

AT also does a lot of other convenience stuff - registering searchable  
fields, creating new indexes/metadata, that kind of stuff. Again, I don't  
see any major gains of separating that out until CMF itself relies on  
adapters for these things.

> anyway, in either event, the first steps are to break it apart into  
> pieces, using the CA to thread it together.  this is going to take a  
> while; it won't be until Plone 3.0 that any of it lands, and it probably  
> won't be until Plone 3.5 that a large percentage of it lands.  that's  
> over a year away, and a lot can change in that time.  i recommend we  
> continue our current path of working on taking it apart, and let the  
> process unfold as we do.

Yeah, 3.5 was my guestimate too. However, we should think about our stance  
towards it. For example, I'd quite like to promote the  
only-the-schema-and-fti-is-in-the-content-class paradigm (OTSATFIITCC, as  
I like to call it)to make the average AT class more lightweight. That'd  
make forward migration a lot more sensible.

I'd also still keep the no-AT-dependency-in-Plone concept (NADIP) intact.  
But we need a firm line on that one.



More information about the Framework-Team mailing list