[Framework-Team] Re: Re: Our attititude to Archetypes

Martin Aspeli optilude at gmx.net
Tue Apr 11 22:07:12 UTC 2006


On Tue, 11 Apr 2006 20:33:43 +0100, Alec Mitchell  
<apm13 at columbia.edu> wrote:

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

This is a good observation. Have we asked, however, what needs to be or  
even makes sense to be componentised?

The reference engine is the obvious example, and possibly a relatively  
easy one (in principle, at least). Hmmm... what else?

I guess the storage layer could use a refactor, but that we've known for a  
while.

There are a lot of things that should be componentised but can't be unless  
CMF starts talking in interfaces. The FTI stuff, the setup stuff - all of  
that needs CMF interfaces that we can adapterise to.

The schema is another story, of course. Actually, I think we should think  
about moving AT's widget system to use Z3's, in which case we'd probably  
need to retain some backwards compatability for a while, but at least it'd  
be easier to re-use. The field/widget system is a mess right now anyway.

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

I absolutely agree. The point of that thread was perhaps slightly more  
general: I want to be able to inject some kind of required or optional  
metadata into every schema or some schemas, based on site policies  
(organisation requires some metadata in all or most cases) and product  
policy (tagging system requires you to enter a tag). It doesn't need to be  
in AT, or in the schema, it just seemed like an obvious option. It just  
needs to be there in a way that's obvious to the user and well-integrated.

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

Agree. But there's lots of CMF boilerplate that's essentially the bit that  
involves deriving form PortalContent. If CMF didn't depend on this large  
monolithic interface, AT would be able to provide some more intelligent  
adapters, but again - so long as logic and view semantics are separated  
 from that, the AT content object can be just as dumb as a class derived  
 from Persistent in pure zope 3 is.


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

Yeah - that was the idea; let people define interfaces like they would in  
pure Zope 3, and just let AT provide the implementation of those  
interfaces on the fly (that's a bit vague, not sure about the details yet).

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

Perhaps you can spell out why? I mean, I agree with you to large extent,  
but we also need to bear in mind that a lot of third party software out  
there is relying on the interfaces Archetypes provides via BaseObject and  
friends, and via the schema. Should we keep writing software that does  
this? If not, we need an alternative fast. :)


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

Well, maybe not. One idea we can try to promote is "if you need an  
interface, write it". I'm sure there are many parts of AT that could be  
generalised out to interfaces (that may or may not already exist), in  
which case we can also consider making "cleaner" new interfaces and  
provide simple adapters. You've got to start somewhere.

Martin
-- 
(muted)




More information about the Framework-Team mailing list