[Product-Developers] Re: plone.behavior, AT and IBehaviorAssignable

Martin Aspeli optilude+lists at gmail.com
Mon Aug 10 16:51:00 UTC 2009


Mikko Ohtamaa wrote:
> Hi,
> 
> plone.behavior is very promising technology.
> 
> I am trying to implement "Header image" behavior for Plone content (all
> content, not just Dexterity based).

Interesting. You'll need to do some plumbing.

> One thing which remains unclear after reading plone.behavior tutorial,
> README and source code is that how IBehaviorAssignable should work. Do I
> create my own MyBehaviorAssignable class which adapts to all IContentish
> content? Isn't this conflicting with every other IBehaviorAssignable out
> there?

Mmmm... it depends.

> If possible I hope the tutorial would meantion IBehaviorAssignable and
> README would contain the pointer how to create one and closing the gap in
> otherwise so perfectly documented component.

The plone.behavior README/PyPI page does explain it. What wasn't clear?

I don't really think this is appropriate for the Dexterity manuals, 
since it's really just low-level framework plumbing.

Basically, you need to allow adaptation from the object that has the 
behavior, to IBehviorAssignable. You could register one for IContentish, 
because the one for IDexterityContent should override it, being more 
specific.

You'd need to decide where to store the behaviour assignments, of 
course. Dexterity stores them in the FTI, of which it has its own type. 
You'd need something different for other types.

The problem (see the README for more details) you'll have, though, is 
that the marker interface support (which is rather important) requires 
that you do one of two things:

  - a custom __providedBy__ descriptor that includes the markers
  - an event handler that adds the markers to new instances

The first approach is better, because it works with "old" instances when 
behaviour assignments change. It is, however, really difficult. You need 
to optimise the crap out of it, since it's called about five hundred 
times per request, so it has to be cached with O(1) lookup. However, 
cache invalidation also needs to be near-perfect, or you get bizarre 
stuff happening when marker interfaces are set or things are changed. 
It's by far the most complex code in plone.dexterity, and it's been 
rewritten about four times.

Also, you'd need a way to get this into every IContentish, which is not 
easy.

The event handler is easier. There's even a handler in plone.behvaior 
for you to use. You'd probably need to modify it, though, so that you 
don't end up fingering Dexterity objects. But changing existing 
instances when the behaviour assignments are changed would either 
require walk-the-ZODB type migration, or some other kind of trick.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book





More information about the Product-Developers mailing list