[Grok-dev] Dolmen and its releases

[Souheil CHELFOUH]

After discussing this matter with several persons, it appears that the
fact the File has its own _p_jar is not really a problem.
As the file is often a "big" chunk of data, it makes sense to has a
separate object, in the zope point of view, so when you load our
object containing a file, you don't load the file with it.
Performance wise, i'd say it doesn't have a negative impact, it's more
than balance by that situation.

What do you guys think ?

2009/10/22 Souheil CHELFOUH <trollfot at gmail.com>:
> 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
>>
>