Schema by Interface / Content Flavors
optilude at gmx.net
Fri Aug 31 07:42:05 UTC 2007
>> Monkey patching is inherently global, so you can't have different
>> methods in different Plone sites.
> Right, I can't have different methods, but is it okay to define methods
> getFoo and setFoo on the type with the understanding that they'll be like
> neglected random appendages in sites that don't extend the content type with
> schema "foo"?
I don't understand the question, but monkey patching is generally
frowned upon and should only be used if necessary.
> It is confusing that ISchema can be used to pull schema from somewhere else,
> but that methods still have to be defined on the class itself - since the
> schema isn't useful without the methods.
Hence why you need something like ContentFlavors. ;-)
> So it seems that adding one field with a locally registered, custom ISchema
> adapter can't be done very cleanly (i.e., without neglected random
> appendages!) and easily. ContentFlavors seems to be a robust set-up but
> perhaps overly complicated for just wanting to add one field with a custom
> ISchema adapter.
I'd like to make it simpler, though I don't have any time (or immediate
personal need) for it right now; I suspect Kapil has similar interests.
The difference with CF's approach, is that it only patches the
*instance*, not the class; it can do that during an "object created"
event, though, so you get it on all objects.
> Could Archetypes allow mutator and accessor methods to be extended with some
> lookup by adapter as well?
If we rewrote major chunks of it, yes. ;-) AT has a fairly annoying
dependency on what ClassGen generates, e.g. for security (it checks
whether method exists and what permissions it has).
borg plone 2.5 branch has a similar mechnism, btw, which still uses a
mix-in class and still is zope-instance-global, using a specialised
ClassGen in response to an event.
> But then I don't know how you would still be able
> to use "context/getFoo".
You couldn't (without hacking __getattr__ or something). In retrospect,
the whole class generation thing is an AT PITA.
> Has there been discussion about how to address the
> schema-by-adapter and expect-methods-on-the-class discrepancy -- perhaps
> with a simpler version of ContentFlavors?
I'd like to make CF a bit easier to use. However, this will never be an
incredibly robust solution. We can make it work, and the use case I have
in mind is something that e.g. wants to inject a field into every/most
content type(s). Think a tagging solution or something.
On the flip-side, it's relatively easy to subclass an existing AT type,
especially with GenericSetup to install it. Sometimes that doesn't work
because other code has hard coded its portal_type.
For example, Poi hard-codes a search for 'PoiIssue', so it's hard to use
a different "issue" implementation without rewriting bits of the tracker
and response object implementations as well. A better way of solving
this in Plone 3, is to use the object_provides index and in general only
search by interface and work through adapters. If Poi had used adapters
and interfaces more sensibly (it couldn't, really, when Plone 2.1 was
out, or at least I didn't know what an adapter was, back then), you may
not have needed a schema patching solution if all you wanted to do was
to capture a few extra fields.
Acquisition is a jealous mistress
More information about the Product-Developers