ImagePreSaveHook should have some way to trigger its execution in case the source part data has not changed

[bruno@…]

[jira2trac import : issue created on April 5, 2007 7:25:43 AM CEST ​http://issues.cocoondev.org/browse/DSY-441 ]

In Daisy 2.0, the ImagePreSaveHook? was 'enhanced' to only redo its work when the part containing the image data changed.

However, this makes it difficult to explicitly trigger the ImagePreSaveHook? in cases like:
 * an upgrade from a pre-1.5 Daisy is done
 * the configuration of the image hook changed
 * or some other reason (e.g. installing JAI) that would cause the image hook to behave in new ways

The only way right now to do this is by making sure the image part data is changed, thus by effectively re-assigning the part data. While this works perfectly, it causes needless growth of the blobstore, and this is what this enhancement wanted to avoid in the first place.

Possible solutions for triggering:
 - some configurable field has some configurable value (e.g. ImageWidth? is set to -1)
 - or more generically, an expression evaluates to true on the document (using QueryManager?.parsePredicateExpression)
 - (add your own)

[paul]

[jira2trac import : comment created by mpo on April 5, 2007 9:05:21 AM CEST]

using imagewidth < 0 is a bit awkward since it can only be triggered programmaticaly (field is not editable in the wiki iirc)
(of course, the ugrade scnario suggests using document tasks anyway, but still)

my personal trigger, and IMHO the most logical one would be to just check that thumbnail and/or preview images don't exist yet (since that checks on the expected endresult effectively)

by the way: the generic 'expression' solution would cover that case, if there would be a DoesNotHavePart?(partname)

[paul]

[jira2trac import : comment created by bruno on April 5, 2007 10:09:36 AM CEST]

Checking for non-existing imagehook-assigned data does indeed seem the logical solution. The reason I have avoided is, is because the data might also be missing because extracting it failed (e.g. invalid or unrecognized image data format). Then again, we might say that this is infrequent enough to do that anyway.

Some programmatic touching of the data will indeed always be necessary.

[paul]

[jira2trac import : comment created by bruno on April 10, 2007 9:52:10 AM CEST]

Fixed in SVN rev 3935.

Followed the strategy of checking for missing extracted data.

From this it also follows that triggering the image-hook to redo its work can be done by deleting one of the parts or fields (not those assigned from exif) assigned by the imagehook.