Dolmen and its releases

[Souheil CHELFOUH]

Hello grokkers !

I've been very busy this week releasing all the things I was keeping
on a code server, rotting alone.
Here are the releases of the week ! I hope you'll take time ti have a
look. They are very close from megrok packages, the only difference is
: they have been coded as a part of a common base, for the Dolmen
project and they are entwined.

For those still foreign to the Dolmen Project, it's a collection of
packages to build applications using Grok.
http://gitweb.dolmen-project.org  -
http://snappy.dolmen-project.org:8080/snappy-demo  (demo application
using Dolmen)

Packages
========

http://pypi.python.org/pypi/dolmen.file
A Zope3/Grok File Representation package.
dolmen.file is a layer above zope.app.file.file.File, adding a notion
of filename, missing in the original implementation.


http://pypi.python.org/pypi/dolmen.blob
Dolmen zodb blob handlers (using ZODB >= 3.9.2)
dolmen.blob is a layer above dolmen.file, using the ZODB blobs as a
storage facility. It respects the zope.app.file IFile and the
dolmen.file INamedFile interfaces.


http://pypi.python.org/pypi/dolmen.storage
Dolmen pluggable and delegated storage
dolmen.storage defines a clear high-level API to deal with pluggable
storage components.


http://pypi.python.org/pypi/dolmen.relations
Dolmen relations
dolmen.relations is a thin layer above zc.relation, allowing a simple
and straightforward implementation of standalone relationships between
objects.


http://pypi.python.org/pypi/dolmen.thumbnailer
Dolmen thumbnailing library
dolmen.thumbnailer is package specialized in Thumbnail generation.
Using the dolmen.storage mechanisms, it allows a pluggable and
flexible thumbnail storage.


http://pypi.python.org/pypi/dolmen.widget.file
File widget for z3c.form, using Grok
dolmen.widget.file is a package that walks hand-in-hand with
dolmen.file. It provides a useable and pluggable way to render the
dolmen.file.FileField in a z3c.form.Form, using Grok (through
megrok.z3cform.base)


http://pypi.python.org/pypi/dolmen.widget.image
Image widget (with thumbnails) for z3c.form, using Grok
dolmen.widget.image is a thin layer above dolmen.widget.file providing
a widget suitable to fields implementing IImageField. It adds, thanks
to dolmen.thumbnailer a preview of the uploaded image in both input
and display mode.



We have also released the first version of megrok.z3cform.base, used
in the project
http://pypi.python.org/pypi/megrok.z3cform.base/0.1"


ENJOY !!
PS : please, let me know if you have any opinions/remarks/wishes/insults
_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martin Aspeli-3]

Souheil CHELFOUH wrote:

Nice to see so many new packages! :-)

> http://pypi.python.org/pypi/dolmen.file
> A Zope3/Grok File Representation package.
> dolmen.file is a layer above zope.app.file.file.File, adding a notion
> of filename, missing in the original implementation.

Is it Grok specific? Otherwise, there's also plone.namedfile, which I
guess does something similar.

>
> http://pypi.python.org/pypi/dolmen.blob
> Dolmen zodb blob handlers (using ZODB >= 3.9.2)
> dolmen.blob is a layer above dolmen.file, using the ZODB blobs as a
> storage facility. It respects the zope.app.file IFile and the
> dolmen.file INamedFile interfaces.

... which is also in plone.namedfile (as an optional extra if you don't
have blob support in your ZODB). :-)

> http://pypi.python.org/pypi/dolmen.relations
> Dolmen relations
> dolmen.relations is a thin layer above zc.relation, allowing a simple
> and straightforward implementation of standalone relationships between
> objects.

How is this different to z3c.relationfield, which I believe is also used
by Grok?

> http://pypi.python.org/pypi/dolmen.thumbnailer
> Dolmen thumbnailing library
> dolmen.thumbnailer is package specialized in Thumbnail generation.
> Using the dolmen.storage mechanisms, it allows a pluggable and
> flexible thumbnail storage.

Cool. What does it use to scale? At what time does it do the scaling?
(upload? download?)

> http://pypi.python.org/pypi/dolmen.widget.file
> File widget for z3c.form, using Grok
> dolmen.widget.file is a package that walks hand-in-hand with
> dolmen.file. It provides a useable and pluggable way to render the
> dolmen.file.FileField in a z3c.form.Form, using Grok (through
> megrok.z3cform.base)

Nice. There's a file widget in plone.formwidget.namedfile, by the way,
although that's possibly a bit more Ploney.

> http://pypi.python.org/pypi/dolmen.widget.image
> Image widget (with thumbnails) for z3c.form, using Grok
> dolmen.widget.image is a thin layer above dolmen.widget.file providing
> a widget suitable to fields implementing IImageField. It adds, thanks
> to dolmen.thumbnailer a preview of the uploaded image in both input
> and display mode.

Again, one can be found in plone.formwidget.namedfile, though that
doesn't have scaling support yet. Hopefully, that'll get added soon,
maybe with the dolmen.thumbnailer thing.

> We have also released the first version of megrok.z3cform.base, used
> in the project
> http://pypi.python.org/pypi/megrok.z3cform.base/0.1"

That's really good to hear. We have some z3c.form-in-Grok stuff in
plone.directives.form. I would like to maybe unify that with something a
bit more Grok specific. I'm hoping that in Plone 4/Zope 2.12 it'll be a
bit easier to use standard z3c.form forms (currently there's a
requirement to wrap forms in a view when using plone.z3cform, which
annoys me a bit).

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@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Souheil CHELFOUH]

2009/10/22 Martin Aspeli <optilude+lists@...>:

> Souheil CHELFOUH wrote:
>
> Nice to see so many new packages! :-)
>
>> http://pypi.python.org/pypi/dolmen.file
>> A Zope3/Grok File Representation package.
>> dolmen.file is a layer above zope.app.file.file.File, adding a notion
>> of filename, missing in the original implementation.
>
> Is it Grok specific? Otherwise, there's also plone.namedfile, which I
> guess does something similar.

Yes, it does something similar. It uses Grok for the registration of
the views and traverser.
This has been started around the same time, it's not meant to be
concurrent. Also, I didn't want to ship any blob things out of the
box.
The dolmen.blob is the package that extends this. This is very
straightforward and no special imports.
dolmen.file also uses and provides what I use a lot myself, the FileProperty.

>
>>
>> http://pypi.python.org/pypi/dolmen.blob
>> Dolmen zodb blob handlers (using ZODB >= 3.9.2)
>> dolmen.blob is a layer above dolmen.file, using the ZODB blobs as a
>> storage facility. It respects the zope.app.file IFile and the
>> dolmen.file INamedFile interfaces.
>
> ... which is also in plone.namedfile (as an optional extra if you don't
> have blob support in your ZODB). :-)

dolmen.blob is very ztk centric and doesn't really support anything zope2-ish
and same remarks : I use a lot the BlobProperty :)


>
>> http://pypi.python.org/pypi/dolmen.relations
>> Dolmen relations
>> dolmen.relations is a thin layer above zc.relation, allowing a simple
>> and straightforward implementation of standalone relationships between
>> objects.
>
> How is this different to z3c.relationfield, which I believe is also used
> by Grok?
This is not meant to act like a field, stored on the object. It's a level lower.
I used to work with z3c.relationfield, but it's too specific. A lot of
the mechanisms are similar,
as it was my start point. Howevern this is more of the framework
level. It would be possible to use
dolmen.relations to make a relationfield-like feature.


>
>> http://pypi.python.org/pypi/dolmen.thumbnailer
>> Dolmen thumbnailing library
>> dolmen.thumbnailer is package specialized in Thumbnail generation.
>> Using the dolmen.storage mechanisms, it allows a pluggable and
>> flexible thumbnail storage.
>
> Cool. What does it use to scale? At what time does it do the scaling?
> (upload? download?)
Actually, it only provides the tools to create the thumbnails with PIL
The trigger of the thumbnailing is left to the discretion of the developper.
Readme tests, they cover most of the features. I personnaly use a
IFieldUpdate adapter, to trigger that, at download time.
But it can be differed in a queue (dolmen.queue is to come)

>
>> http://pypi.python.org/pypi/dolmen.widget.file
>> File widget for z3c.form, using Grok
>> dolmen.widget.file is a package that walks hand-in-hand with
>> dolmen.file. It provides a useable and pluggable way to render the
>> dolmen.file.FileField in a z3c.form.Form, using Grok (through
>> megrok.z3cform.base)
>
> Nice. There's a file widget in plone.formwidget.namedfile, by the way,
> although that's possibly a bit more Ploney.

>
>> http://pypi.python.org/pypi/dolmen.widget.image
>> Image widget (with thumbnails) for z3c.form, using Grok
>> dolmen.widget.image is a thin layer above dolmen.widget.file providing
>> a widget suitable to fields implementing IImageField. It adds, thanks
>> to dolmen.thumbnailer a preview of the uploaded image in both input
>> and display mode.
>
> Again, one can be found in plone.formwidget.namedfile, though that
> doesn't have scaling support yet. Hopefully, that'll get added soon,
> maybe with the dolmen.thumbnailer thing.
>

It's directly tied to the thumbnailer and it's merely a thin layer
about the file widget.
The widgets are registered with megrok.z3cform.base

>> We have also released the first version of megrok.z3cform.base, used
>> in the project
>> http://pypi.python.org/pypi/megrok.z3cform.base/0.1"
>
> That's really good to hear. We have some z3c.form-in-Grok stuff in
> plone.directives.form. I would like to maybe unify that with something a
> bit more Grok specific. I'm hoping that in Plone 4/Zope 2.12 it'll be a
> bit easier to use standard z3c.form forms (currently there's a
> requirement to wrap forms in a view when using plone.z3cform, which
> annoys me a bit).
>
> Martin
>

I forgot the dolmen.storage, which I use a lot !

http://pypi.python.org/pypi/dolmen.storage
Dolmen Zope3 Grok Storage Annotation
dolmen.storage defines a clear high-level API to deal with pluggable
storage components.
This is an alternative to the grok.annotation use.
_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martin Aspeli-3]

Souheil CHELFOUH wrote:
> 2009/10/22 Martin Aspeli <optilude+lists@...>:
>> Souheil CHELFOUH wrote:
>>
>> Nice to see so many new packages! :-)
>>
>>> http://pypi.python.org/pypi/dolmen.file

provides what I use a lot myself, the FileProperty.

How does that work?

>>> http://pypi.python.org/pypi/dolmen.blob

> dolmen.blob is very ztk centric and doesn't really support anything zope2-ish
> and same remarks : I use a lot the BlobProperty :)

plone.namedfile works fine without blobs too. It's totally optional. I
don't think it makes much difference.

>>> http://pypi.python.org/pypi/dolmen.relations

> This is not meant to act like a field, stored on the object. It's a level lower.
> I used to work with z3c.relationfield, but it's too specific. A lot of
> the mechanisms are similar,
> as it was my start point. Howevern this is more of the framework
> level. It would be possible to use
> dolmen.relations to make a relationfield-like feature.

May be interesting in cases where fields are not really what you're after.

> I forgot the dolmen.storage, which I use a lot !

No you didn't, I snipped it. :)

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@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Souheil CHELFOUH]

the field property is a property that handles the persistency of your
data transparently. And because code is always better than bad english
explanations:


>>> from persistent import Persistent
>>> from dolmen.file import FileProperty, FileField
>>> from zope.interface import Interface, implements

>>> class IContent(Interface):
...     binary = FileField(title=u"Binary data")

>>> class MyContent(Persistent):
...     implements(IContent)
...     binary = FileProperty(IContent['binary'])


>>> root['mammoth'] = MyContent()
>>> manfred = root['mammoth']
>>> manfred.binary = FileChunk('Foobar')
>>> manfred.binary
<dolmen.file.file.NamedFile object at ...>

>>> manfred.binary.data
'Foobar'


2009/10/22 Martin Aspeli <optilude+lists@...>:

> Souheil CHELFOUH wrote:
>> 2009/10/22 Martin Aspeli <optilude+lists@...>:
>>> Souheil CHELFOUH wrote:
>>>
>>> Nice to see so many new packages! :-)
>>>
>>>> http://pypi.python.org/pypi/dolmen.file
>
> provides what I use a lot myself, the FileProperty.
>
> How does that work?
>
>>>> http://pypi.python.org/pypi/dolmen.blob
>
>> dolmen.blob is very ztk centric and doesn't really support anything zope2-ish
>> and same remarks : I use a lot the BlobProperty :)
>
> plone.namedfile works fine without blobs too. It's totally optional. I
> don't think it makes much difference.
>
>>>> http://pypi.python.org/pypi/dolmen.relations
>
>> This is not meant to act like a field, stored on the object. It's a level lower.
>> I used to work with z3c.relationfield, but it's too specific. A lot of
>> the mechanisms are similar,
>> as it was my start point. Howevern this is more of the framework
>> level. It would be possible to use
>> dolmen.relations to make a relationfield-like feature.
>
> May be interesting in cases where fields are not really what you're after.
>
>> I forgot the dolmen.storage, which I use a lot !
>
> No you didn't, I snipped it. :)
>
> 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@...
> https://mail.zope.org/mailman/listinfo/grok-dev
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martin Aspeli-3]

Souheil CHELFOUH wrote:

> the field property is a property that handles the persistency of your
> data transparently. And because code is always better than bad english
> explanations:
>
>
>>>> from persistent import Persistent
>>>> from dolmen.file import FileProperty, FileField
>>>> from zope.interface import Interface, implements
>
>>>> class IContent(Interface):
> ...     binary = FileField(title=u"Binary data")
>
>>>> class MyContent(Persistent):
> ...     implements(IContent)
> ...     binary = FileProperty(IContent['binary'])

What does this do above and beyond just setting an object onto the
instance (like plone.namedfile or zope.app.file or z3c.blobfile do)?
Extra validation?

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@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Souheil CHELFOUH]

2009/10/22 Martin Aspeli <optilude+lists@...>:

> Souheil CHELFOUH wrote:
>> the field property is a property that handles the persistency of your
>> data transparently. And because code is always better than bad english
>> explanations:
>>
>>
>>>>> from persistent import Persistent
>>>>> from dolmen.file import FileProperty, FileField
>>>>> from zope.interface import Interface, implements
>>
>>>>> class IContent(Interface):
>> ...     binary = FileField(title=u"Binary data")
>>
>>>>> class MyContent(Persistent):
>> ...     implements(IContent)
>> ...     binary = FileProperty(IContent['binary'])
>
> What does this do above and beyond just setting an object onto the
> instance (like plone.namedfile or zope.app.file or z3c.blobfile do)?
> Extra validation?
>

Have a look at the code itself
http://gitweb.dolmen-project.org/dolmen.file.git/blob/adf9207a69037e770838b35ed381ba942f6efdbf:/src/dolmen/file/property.py

> 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@...
> https://mail.zope.org/mailman/listinfo/grok-dev
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martin Aspeli-3]

Souheil CHELFOUH wrote:

> Have a look at the code itself
> http://gitweb.dolmen-project.org/dolmen.file.git/blob/adf9207a69037e770838b35ed381ba942f6efdbf:/src/dolmen/file/property.py

Ah, so it's like acquisition: set a __parent__ pointer on get.

Note that this means you're effectively doing a ZODB write one very
read, which is possibly bad for conflict errors and the like (unless
there's some non-persistence magic in __parent__?)

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@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Souheil CHELFOUH]

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.

2009/10/22 Martin Aspeli <optilude+lists@...>:

> Souheil CHELFOUH wrote:
>
>> Have a look at the code itself
>> http://gitweb.dolmen-project.org/dolmen.file.git/blob/adf9207a69037e770838b35ed381ba942f6efdbf:/src/dolmen/file/property.py
>
> Ah, so it's like acquisition: set a __parent__ pointer on get.
>
> Note that this means you're effectively doing a ZODB write one very
> read, which is possibly bad for conflict errors and the like (unless
> there's some non-persistence magic in __parent__?)
>
> 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@...
> https://mail.zope.org/mailman/listinfo/grok-dev
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martin Aspeli-3]

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@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Souheil CHELFOUH]

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@...>:

> 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@...
> https://mail.zope.org/mailman/listinfo/grok-dev
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[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@...>:

> 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@...>:
>> 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@...
>> https://mail.zope.org/mailman/listinfo/grok-dev
>>
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martin Aspeli-3]

Souheil CHELFOUH wrote:
> 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 ?

I think it depends on your use case:

  - if you've got a big file, it should be a blob; in this case, the
blob container (which also stores filename etc) probably shouldn't be a
separate persistent object, since the blob is one already.

  - if you have a small file and you will render its contents often when
the object is loaded, avoiding a separate object load may be beneficial

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@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Souheil CHELFOUH]

What you say only worths for the Blobs.
For a non-blob file, it makes sense to keep a separate file.
It's easy to provide a non Persistent version of a blob
It's not for a File, since zope.app.file inherit itself from Persistent.

There is at least on interest motivating a separate blob object,
containing a Blob:
It can be moved out of your object and act as a normal object.

That being, providing a "BlobValue" is trivial
providing a FileValue is senseless

I wonder what the performace impact is, keeping a BlobFile with an
independant connection as an attribute.
It can think of several usecases, that would modify the BlobFile
itself and not the object containing it.

How do you solve that, in Plone, to handle an object containing a
named blob file ?
I didn't see any solution provided for that in plone.namedfile

2009/10/23 Martin Aspeli <optilude+lists@...>:

> Souheil CHELFOUH wrote:
>> 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 ?
>
> I think it depends on your use case:
>
>  - if you've got a big file, it should be a blob; in this case, the
> blob container (which also stores filename etc) probably shouldn't be a
> separate persistent object, since the blob is one already.
>
>  - if you have a small file and you will render its contents often when
> the object is loaded, avoiding a separate object load may be beneficial
>
> 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@...
> https://mail.zope.org/mailman/listinfo/grok-dev
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Souheil CHELFOUH]

I released a new version :
http://pypi.python.org/pypi/dolmen.blob/0.2

If people are interested to review it, i'll be most happy
Thank you Martin for your tips and feedback.


2009/10/23 Souheil CHELFOUH <trollfot@...>:

> What you say only worths for the Blobs.
> For a non-blob file, it makes sense to keep a separate file.
> It's easy to provide a non Persistent version of a blob
> It's not for a File, since zope.app.file inherit itself from Persistent.
>
> There is at least on interest motivating a separate blob object,
> containing a Blob:
> It can be moved out of your object and act as a normal object.
>
> That being, providing a "BlobValue" is trivial
> providing a FileValue is senseless
>
> I wonder what the performace impact is, keeping a BlobFile with an
> independant connection as an attribute.
> It can think of several usecases, that would modify the BlobFile
> itself and not the object containing it.
>
> How do you solve that, in Plone, to handle an object containing a
> named blob file ?
> I didn't see any solution provided for that in plone.namedfile
>
> 2009/10/23 Martin Aspeli <optilude+lists@...>:
>> Souheil CHELFOUH wrote:
>>> 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 ?
>>
>> I think it depends on your use case:
>>
>>  - if you've got a big file, it should be a blob; in this case, the
>> blob container (which also stores filename etc) probably shouldn't be a
>> separate persistent object, since the blob is one already.
>>
>>  - if you have a small file and you will render its contents often when
>> the object is loaded, avoiding a separate object load may be beneficial
>>
>> 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@...
>> https://mail.zope.org/mailman/listinfo/grok-dev
>>
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev