[Grok-dev] Dolmen and its releases

Souheil CHELFOUH trollfot at gmail.com
Thu Oct 22 11:31:04 EDT 2009

This is a convenient component proposed for people who use it and want it
The package can still work through a basic NamedFile attribute, it
changes nothing.
And yes, I thought about some of the problems you raised in here and
I'll need to put my attention on this, obviously... I'd need another
life to do all the things I should do :)
That's a good point, for the Persistent inheritance. I guess I'd need
a file value, different from the NamedFile persistent object.

2009/10/22 Martin Aspeli <optilude+lists at gmail.com>:
> Souheil CHELFOUH wrote:
>> This is one thing. The most interesting part is that we effectively
>> respect the interface, providing the default, respecting the readonly,
>> etc.
>> For the __parent__ thing, i need to work on it more closely. I'll
>> probably return a containment proxy instead.
> Just a couple of suggestions from someone who's recently been working on
> very similar things (plone.namedfile, plone.app.textfield):
>  - avoid proxies if you can; they cause confusion and another layer of
> indirection
>  - if you need a proxy, there's the one from zope.location
>  - ask yourself why it needs to know the __parent__ - avoid if you can
>  - setting immutable 'value' object is better than having a mutable
> value object. You almost never need to change it, and making them
> mutable means you have to worry about persistence
>  - a 'value' object probably shouldn't derive from Persistent, since it
> means you're getting a new ZODB p_jar for each one in addition to the
> parent object; you want to be in the same jar as the parent most of the
> time (or in a blob)
>  - field properties that do readonly, default (mmm, you probably want
> missing_value) etc sound neat, but are less useful in practice. There's
> FieldProperties in the ZTK of course that basically do most of what you
> are doing except the __praent__ thing
> Martin
> --
> Author of `Professional Plone Development`, a book for developers who
> want to work with Plone. See http://martinaspeli.net/plone-book
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev

More information about the Grok-dev mailing list