Hi,

thanks Goerges, it is working.

At the moment, this type holds the original image and calculates a
thumbnail, additionally it stores the thumbnail size in a int Field.

I'd like to be able to change the thumbnail size field value and then
re-thumbnail the original image. At the moment, since the original
image data is not changed, it justs preserves both images.

How could i achieve this?

Further, the next step would be, that when imagegallery's thumbnail
size fields are changed, then this should be somehow propagated to the
contained objects of this type.
Maybe thios could be solved with a new action without customizing the
document edit method.

Thanks, Michael

2007/4/13, Georges Racinet <[EMAIL PROTECTED]>:

On Apr 13, 2007, at 3:02 PM, Michael Schulz wrote:

> Thanks,
>
> if I understand it right, your suggestion means:
>
> - create CPSImageWithThumbnailField(CPSImageField), with a
> computeDependantFields method, that takes the original imagefield
> data, uses PIL to create the thumbnail and write the new image to the
> thumbnail field.

Yes, make the name (or better, suffix) of the dependent field
configurable through a property.
Check CPSFileField declaration (in CPSSchema/BasicFields.py)

>
> - change my Photo schema, to one CPSImageWithThumbnailField and one
> CPSImageField(?) or two CPSImageWithThumbnailFields

The first of these possiblities, where of course you name the
thumbnail field according to what you
configured in the main one

>
> - what layout should i choose? since i still want to be able to use it
> TTW: change my layout, so that instead of using a photo widget I use a
> normal image widget and on each change of the image, the thumbnail
> field is updated thru the computedependantfields method?

I'm don't remember that well what PhotoWiget does. Anyway, you can use
your field with any Image oriented widget.

>
> - If i then use the remote controller or createFile it is sufficient
> to provide the image file in the doc_def, because again,
> computedependantFields would thumbnail...

Yes. More precisely, this happens at DataModel commit time.

>
> Did I get that right? Thanks, Michael

Seems so, yes !


>
>
> 2007/4/13, Georges Racinet <[EMAIL PROTECTED]>:
>>
>> On Apr 13, 2007, at 12:16 PM, Michael Schulz wrote:
>>
>> > Hi,
>> >
>> > I am looking for a solution to the behaviour mentioned in this
>> ticket
>> > about the imagegallery type: http://svn.nuxeo.org/trac/pub/
>> ticket/693
>> >
>> > I thought a quick solution to this could be to create a new
>> > CPSDocumentType ("Photo"), that uses the photo widget, which can
>> store
>> > the original image plus a generated thumbnail. The resizing and
>> > keeping original image data is done in ExtendedWidget and
>> BasicWidget
>> > modules.
>> >
>> > After adding this Photo type to the allowed_content_types of the
>> > imagegallery, it is working for images that are uploaded thru the
>> > normal forms. But creating this type thru a zipfile upload is not
>> > working: the object is created, but the resizing and keeping of
>> > original data is not performed. Presumably because this
>> functionality
>> > comes from the widget "machinery", that is not invoked through the
>> > process when uploading a zipfile (createFile.py).
>> >
>> > What would be the correct manner to create these objects by
>> scripts?
>> > The same problem arises when trying to create this type through the
>> > remote controller.
>> >
>> > TIA, Michael
>>
>> Hi
>>
>> I think you'd want to use the computeDependantFields (sic) method of
>> fields. So instead of
>> subclassing the Image widget, you could subclass the CPS ImageField,
>> and have it take care of the
>> thumbnail. This should catch all these use cases. For example, I've
>> done this to read ID3 tags from MP3 files.
>> In mainstream CPS, this is used to apply transforms, like converting
>> pdf to text for indexing.
>>
>>
>> >
>> > --
>> > -----------------------------------------------------------
>> > Michael Schulz
>> > [EMAIL PROTECTED]
>> >
>> > in medias res
>> > Gesellschaft für Informationstechnologie mbH
>> >
>> > In den Weihermatten 66
>> > 79108 Freiburg
>> >
>> > Tel  +49 (0)761 556959-5
>> > Fax +49 (0)761 556959-6
>> >
>> > http://www.webgis.de / http://www.zopecms.de
>> > -----------------------------------------------------------
>> > _______________________________________________
>> > cps-devel mailing list
>> > http://lists.nuxeo.com/mailman/listinfo/cps-devel
>> >
>>
>> ---------
>> Georges Racinet,   Nuxeo SAS
>> Open Source Enterprise Content Management (ECM)
>> Web: http://www.nuxeo.com/ and http://www.nuxeo.org/ - Tel: +33 1 40
>> 33 79 87
>>
>>
>>
>> _______________________________________________
>> cps-devel mailing list
>> http://lists.nuxeo.com/mailman/listinfo/cps-devel
>>
>
>
> --
> -----------------------------------------------------------
> Michael Schulz
> [EMAIL PROTECTED]
>
> in medias res
> Gesellschaft für Informationstechnologie mbH
>
> In den Weihermatten 66
> 79108 Freiburg
>
> Tel  +49 (0)761 556959-5
> Fax +49 (0)761 556959-6
>
> http://www.webgis.de / http://www.zopecms.de
> -----------------------------------------------------------
>

---------
Georges Racinet,   Nuxeo SAS
Open Source Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ and http://www.nuxeo.org/ - Tel: +33 1 40
33 79 87






--
-----------------------------------------------------------
Michael Schulz
[EMAIL PROTECTED]

in medias res
Gesellschaft für Informationstechnologie mbH

In den Weihermatten 66
79108 Freiburg

Tel  +49 (0)761 556959-5
Fax +49 (0)761 556959-6

http://www.webgis.de / http://www.zopecms.de
-----------------------------------------------------------
_______________________________________________
cps-devel mailing list
http://lists.nuxeo.com/mailman/listinfo/cps-devel

Reply via email to