On Tue, 11 Apr 2006 19:07:03 +0100, Rob Miller
<[EMAIL PROTECTED]> 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
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.
Framework-Team mailing list