[Framework-Team] Re: Our attititude to Archetypes

[Alec Mitchell]

On 4/11/06, Martin Aspeli <optilude at gmx.net> wrote:
> 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.


I think much of the power of AT lies in how intertwined all its parts
are, and while there's a great deal of value there, I think there's a
high likelihood that componentizing it will become quite difficult as
we move deeper into the AT core.

> 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
> views.

I think efforts are better focused on making the non-core pieces of AT
full-fledged reuasble components, than on trying to reimplement the
core using component-y techniques.  Once we have these tools
componentized (references, transforms), I think it's more likely that
the sensible path will be to try and bring the remaining AT
functionality over into z3-schema land.

> 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 only boilerplate that AT really minimizes is the FTI stuff, and
this is honestly a pretty trivial bit of code that generates an FTI
from some class variables.  Replicating this for z3-schemas, or
perhaps via some fancy new zcml, shouldn't be that hard.

> 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.

Actually, I don't think attribute storage poses a problem here, but
dealing with the security machinery may.  I have no idea how to make
z3 style set/get permission declarations for properties dynamically. 
It's probably not too difficult though, but it's moving one of those
things that really belongs in zcml config into python code.  If the
types are defined by a z3 schema then, this ecomes quite easy.

> 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.

Right, none of these thing are terribly difficult problems to solve
though.  The bulk of AT, it seems to me, is schema stuff and
class/method generation (which includes storage, etc.).  Those are
things that I personally would like to see us move away from.

> > 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.

Once we have these things componentized with well defined interfaces
it should be easy enough for plone to simply depend on a particular
interface, rather than any specific implementation like AT.  However
the big disadvantage of AT in this regard is that the AT Schema is not
itself an interface, and making it one is likely to be
counter-productive.

Alec