On Tue, 11 Apr 2006 20:33:43 +0100, Alec Mitchell
<[EMAIL PROTECTED]> 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
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
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)
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
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.
Framework-Team mailing list