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

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

Reply via email to