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

[Alec Mitchell]

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

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.

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

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

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

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

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.

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

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

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

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

But this isn't the same as having schema == interface, which seems
like a pretty obvious thing to want once you have interfaces.

Alec