Defined sequence of Pre-save Hooks? [Edit graphics in wiki.]

[Rolf Sigg]

Hi,

How can I define the execution sequence of multiple pre-save hooks?

Background: I extended the ImageDocument type with an additional
AttachmentData Part and implemented a pre-save hook, which generates the
bitmap (ImageData) out of the attachment data if the data format in the
attachment is known. Everything seems to work out, except that the
thumbnail pre-save hook is executed before our pre-save hook such that
the thumbnails are not up-to-date.

[Together with the download-edit-upload applet, this gives a good
compromise between end-user experience, development effort and daisy
version compatibility. Of course, an own part-editor would give better
user experience (e.g. like the gliffy plugin in atlassian confluence).]

Thanks in advance,
Rolf
_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[Karel Vervaeke]

You don't have much control over it I'm afraid.
The only thing controlling it is the order in which the hooks are
registered (pluginRegistry.add(PreSaveHook.class, ...)).

You have a little control over it by putting your hook in
load-before-repository or load-after-repository.
Other than that, I believe the jar files within those directories are
loaded alphabetically - but I think
it wouldn't be a very good practice to go depeding on that.

HTH,
Karel


On Mon, Sep 7, 2009 at 1:23 PM, Rolf Sigg<rolf.sigg@...> wrote:

>
> Hi,
>
> How can I define the execution sequence of multiple pre-save hooks?
>
> Background: I extended the ImageDocument type with an additional
> AttachmentData Part and implemented a pre-save hook, which generates the
> bitmap (ImageData) out of the attachment data if the data format in the
> attachment is known. Everything seems to work out, except that the thumbnail
> pre-save hook is executed before our pre-save hook such that the thumbnails
> are not up-to-date.
>
> [Together with the download-edit-upload applet, this gives a good compromise
> between end-user experience, development effort and daisy version
> compatibility. Of course, an own part-editor would give better user
> experience (e.g. like the gliffy plugin in atlassian confluence).]
>
> Thanks in advance,
> Rolf
> _______________________________________________
> daisy community mailing list
> Professional Daisy support:
> http://outerthought.org/en/services/daisy/support.html
> mail to: daisy@...
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>

_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[Rolf Sigg]

Karel Vervaeke schrieb:
> You don't have much control over it I'm afraid.
> The only thing controlling it is the order in which the hooks are
> registered (pluginRegistry.add(PreSaveHook.class, ...)).
>
> You have a little control over it by putting your hook in
> load-before-repository or load-after-repository.
> Other than that, I believe the jar files within those directories are
> loaded alphabetically - but I think
> it wouldn't be a very good practice to go depeding on that.

Ok, thanks for the information.

Both load-before-repository and load-after-repository seem to be loaded
after the daisy built-in functionality (including the image pre-save
hook) and therefore do not solve my current problem.

I also tried to replace the existing image pre-save hook with an
extended one that adds our functionality such that only one pre-save
hook exists. However, the ImagePreSaveHook class seems not to be
intended to be extended... (registers itself with a name from private
field in constructor).

I think the best solution will be to introduce an own document type and
to adapt the skin to treat our new document type the same way as image
document types. Optionally, the rendering could be moved from a pre-save
hook to a cocoon serializer. This trades storage space for CPU and gives
the possibility to use a high resolution image in PDFs.
_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

[Karel Vervaeke]

On Mon, Sep 14, 2009 at 1:31 PM, Rolf Sigg<rolf.sigg@...> wrote:

> Karel Vervaeke schrieb:
>>
>> You don't have much control over it I'm afraid.
>> The only thing controlling it is the order in which the hooks are
>> registered (pluginRegistry.add(PreSaveHook.class, ...)).
>>
>> You have a little control over it by putting your hook in
>> load-before-repository or load-after-repository.
>> Other than that, I believe the jar files within those directories are
>> loaded alphabetically - but I think
>> it wouldn't be a very good practice to go depeding on that.
>
> Ok, thanks for the information.
>
> Both load-before-repository and load-after-repository seem to be loaded
> after the daisy built-in functionality (including the image pre-save hook)
> and therefore do not solve my current problem.

Bummer. You're right.

>
> I also tried to replace the existing image pre-save hook with an extended
> one that adds our functionality such that only one pre-save hook exists.
> However, the ImagePreSaveHook class seems not to be intended to be
> extended... (registers itself with a name from private field in
> constructor).
>
> I think the best solution will be to introduce an own document type and to
> adapt the skin to treat our new document type the same way as image document
> types. Optionally, the rendering could be moved from a pre-save hook to a
> cocoon serializer. This trades storage space for CPU and gives the
> possibility to use a high resolution image in PDFs.
> _______________________________________________

That seems like a good way to continue...

> daisy community mailing list
> Professional Daisy support:
> http://outerthought.org/en/services/daisy/support.html
> mail to: daisy@...
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>
_______________________________________________
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy