Schema by Interface / Content Flavors

Martin Aspeli optilude at gmx.net
Fri Aug 31 07:42:05 UTC 2007


sirgarr wrote:

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

Martin

-- 
Acquisition is a jealous mistress





More information about the Product-Developers mailing list