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
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
