[ZODB-Dev] Python properties on Persistent objects

[Martin Aspeli]

Mikko Ohtamaa wrote:
>> This isn't right: a z3c.form form is just a view like any other. It is
>> looked up on the context and the request. In Dexterity (which I assume
>> you're using?), that's going to be the content object.
>
> Sorry, I think I mixed with zope.formlib. In any case I hope to find
> the answer to the orignal question.
>
> The original pattern which I copied is is here:
> http://code.google.com/p/getpaid/source/browse/Products.PloneGetPaid/trunk/Products/PloneGetPaid/preferences.py

That code is insane. Really insane. It's generating classes and doing 
custom adapter factories that inject a _v_ variable into a persistent 
object temporarily. I wouldn't try to copy it at all. I would run away.

I *think* what may be happening here is that most of the vocabularies in 
plone.app.vocabularies have code like this:

    context = getattr(context, 'context', context)

This hack is there to support the IAdding view use case where the 
context of the add form is another view and the first "real" content 
object from which you can acquire stuff is self.context.context. We're 
moving away from that in favour of not acquiring tools and not using 
views-on-views, which are evil anyway. Hence, the 'context' property in 
StoreSettings, which I presume is used as the context for a form, is 
being cajoled into being the Plone site root. But that's using a hack to 
trick a hack into doing different hackery.

This is getting far off topic for the ZODB list, but if you can explain 
what problem you're actually trying to solve, I'm sure we can come up 
with a suggestion that is less of an architecture spacewalk.

When you start having to ask the ZODB list, maybe it's time to think 
whether you could find a simpler solution. :-)

> I don't think I am doing it incorrectly. The other reason of using
> this pattern is that the behavior factory does not need to have a
> write or (an extra) object load if the behavior is never set on the
> context object. The default object returned by factory acts similar
> than the persistent object and I can set the behavior defaults using
> zope.schema - I don't need to do "if not set" logic anywhere else in
> my code.

There is no reason you can't get this "don't-write-unless-necessary" 
behaviour in a much more sane way. In fact, it ought to be the default. 
To help you, I'd need a more comprehensive understanding of what you're 
doing and why, though.

Martin

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