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

Martin Aspeli optilude at gmx.net
Wed Apr 12 07:47:26 UTC 2006

On Wed, 12 Apr 2006 00:05:29 +0100, Alec Mitchell  
<apm13 at columbia.edu> wrote:

>> The reference engine is the obvious example, and possibly a relatively
>> easy one (in principle, at least). Hmmm... what else?
> It's not necessarily that easy as the implementation is tied pretty
> deeply into AT, and there's a lot of unexpected oddness going on
> (partly the result of not having any well defined interfaces).  It is
> doable though.  Componentizing PortalTransforms is equally valuable
> and probably even easier.  The validation machinery is possibly
> another good candidate.

Indeed. Transforms is a good one. For validation, we need to think  
carefully about how zope 3 schemas do validation as well.

Also, I think we should try to be pragmatic - if some corner case of AT's  
behaviour is particularly broken, we should rather implement a clean  
solution and work on backward compatability through our adapters and the  
existing APIs, rather than take the whole thing wholesale.

>> I guess the storage layer could use a refactor, but that we've known  
>> for a
>> while.
> I personally think that plugable field level storage, in the manner
> that AT does it, is mostly a failed experiment.  It might be
> interesting to do something with the CA that allows for easily
> creating objects which primarily store data outside the ZODB, but a
> lot of thought needs to go into it.  I think it would be a mistake to
> try to reimplement the Storage mechanisms of AT.

That's exactly what I meant. :)

Storing things outside the ZODB is really valuable and still too  
difficult. SQLStorage is the prime example of why the AT model doesn't  
work (no concept of real transactions when you're saving or loading).  
Again, this is a case of something we may need to solve outside AT and  
then hook AT into.

>> 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.
> I'm not sure what you mean here.  What will CMF talking in interfaces  
> help with?

At the moment, CMF (though it's getting better as Rob points out) expects  
a content class to have a whole bunch of methods. Since it's not looking  
up adapters by interface, we need a large, monolithic PortalContent as a  
base class. If it were doing adapter lookups, we could break the pieces  
off PortalContent into separate adapters that could be more easily  

>> 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.
> And if we do this, what is left of AT?

heh :-)

Mostly the schemas of all the content types that are out there, and the  
other software that are relying on AT's general APIs (i.e. I get get an  
object's schema, iterate over it, do something with each field). And it's  
not necessarily a bad thing. The AT schema itself, i.e. the only part that  
90% of developers use, is quite declarative and generic.

>> 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.
> Zope3 is currently not able to do persistent schemas, because schemas
> are themselves interfaces, which are not easily persisted.  If it
> could, then this sort of thing would be trivial, so that's an
> advantage for AT.  But implementing something like this shouldn't be
> too hard, you should be able to persist a list of z3 fields and use
> that as the source for form generation for a metadata adapter of some
> sort.  For AT, this sort of problem has already been solved with ATSE,
> which allows you to lookup schemas centrally.  The problem is that the
> current implementation requires you to mixin a new base class, but
> that should be easy to overcome if it's considered desirable.

Right. The larger question is, do we want to tie this to AT, or find a  
more general way? If Plone wants to enable some UI mechanism that letrs  
you inject metadata like that, should that mechanism be tied to AT, or  
should AT just provide an implementation of it?

>> > 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.
> If we want CMF content we are going to have to subclass PortalContent,
> which honestly isn't that much of a burden.  It consists of one method
> for webdav lock checking (failIfLocked) which probably belongs in a
> different interface, a method to aid in catalog searches
> (SearchableText) which certainly belongs someplace else, and methods
> to lookup the default view, which are unnecessary if we start using z3
> views for this stuff, but necessary otherwise.  It subclasses
> CMFCatalogAware, which will hopefully become less relevant as we move
> towards z3 events, DynamicType which essentially just provides
> portal_type, and SimpleItem which is essentially a necessity for any
> content that wants to exist in Zope2 (and is by far the most complex
> part of the PortalContent mixin).  I'm pretty sure that nobody in the
> z3 world wants what AT is offering (in terms of schemas, widgets,
> fields, storage), so removing the CMF dependency isn't really going to
> gain anybody much of anything.

Hmmm... you're probably right. Again, I sort of came to this point by  
realising that if the AT content class is just about persistent fields,  
and logic is in other adapters, then the software as a whole is more  
managable and re-usable.

Ben raised a good point on IRC last night. Either we try to find the most  
perfect looking API (where perfect == zope 3 these days, it seems), or we  
try to drive our story for content types forward. Ben mentioned things  
like adaptive schemas (he has a branch, apparently), haystack, eventually.  
There's innovation to be had still, and it will probably build on AT since  
that's the best we've got. The question is, should put the breaks on that  
until we "fix" AT or get rid of it (neither of which seems very likely any  
time soon, and they may not even be that necessary if we solve a few core  
problems), or do we forge ahead? We need an answer to those who want to  
produce something now, not at some indefinite point in the future.

>> > 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).
> Why can't z3 provide the implementations of those interfaces on the fly?

Sorry, probably not very clear. What I meant was, if I define IMyContent  
that has a property foo, then the interface would want me to access  
myContent.foo, whereas AT, with a field 'foo' would want me to access  
myContent.getFoo() etc. It may be useful (in the interim, at least) if  
people can define a "pure" Z3 schema, but use Archetypes to implement it,  
thus getting base_edit and validation and transforms and all the rest of  

> The reason I want to move away from this is that we are on our own
> path here with AT.  It is Plone's and Plone's alone, and worse,
> there's apparently not much interest, even among Plone developers, in
> working on it or even maintaining it (except when absolutely
> necessary, even then often not).   The z3 folks have a lot of nice
> technology, including an implementation of schemas, fields, and
> widgets which is pretty clean, and which allows for have multiple
> schemas per object, applying schemas to objects through simple
> configuration, among other useful things.  Importantly the z3 version
> is actively developed and has a reasonable roadmap.  I think
> re-hitching our wagons to a vital project with broader acceptance is a
> reasonable step (especially since it's already included as a
> dependency).  However, at the moment it doesn't provide everything we
> need.  That's why I'm with Rob in thinking we should componentize
> those bits and pieces of AT which are broadly useful.  We can make
> them available and desirable to the larger zope and python
> communities, and then see what's left.


> I think for the time being we need to keep writing software with AT
> until we have an real alternative, but if we try too hard to make the
> next iteration of whatever schema based content creation framework
> compatible with AT, we may well be shooting ourselves in the foot (at
> least with regard to the story of moving closer to the state of the
> art in Zope and CMF-land is concerned).

I absolutely agree. Which is why I think we need to think about forward  
compatability now. There are lots of cool things we could build onto AT,  
the schema injection thing being only one. But if we do that, we're  
widening the gap, not narrowing it. So we need patterns and policies that  
help us approach these problems and that we can communicate to the wider  

>> 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.
> But this isn't the same as having schema == interface, which seems
> like a pretty obvious thing to want once you have interfaces.

Sorry, I meant ... if we're working on AT core (or Plone core) and it'd be  
natural to write to some interface that doesn't exit yet, create that  
interface and wire it up, don't forge ahead making assumptions about an  
under-defined API.


More information about the Framework-Team mailing list