On Wed, 12 Apr 2006 00:05:29 +0100, Alec Mitchell
<[EMAIL PROTECTED]> 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
interchangable.
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
it.
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.
+10
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
world.
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.
Martin
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
