Uploading images asynchronuously

In version 1.09.00 of GalleryPickerPlugin it has become possible to upload and scale images directly from the LinkPicker dialog. This addition is done for the DCR project and is used quit often by the CMS users.

The CMS end user at the Dutch libraries use the feature often. However, if the upload and scaling of the image takes a long time the users start to click on the uploading button or the cancel / reset button.
When this happens various things can happen, for instance the uploading and scaling is stopped involuntary, or the image is uploaded and scaled several times (with more waiting time as result).
Sometimes the users report incomplete documents (missing scaling variants), and this is maybe caused by clicking during the upload.

This is the simplified code in the GalleryPickerDialog which extends LinkPickerDialog :

@Override
protected void onSubmit(AjaxRequestTarget target, Form<?> form) {

final FileUpload upload = uploadField.getFileUpload();
if (upload != null) {
try

{ // get workflow // upload file // create document (delegated to the workflow) // retrieve the node from the session // if the node exists, then scale the gallery variants // save // add the uploadField to the component }

else

{ error("Please select a file to upload"); }

As you can see, the user is blocked during the processing and the code is not proof against users "killing" the dialogue during the uploading.

So we would like to improve this extension in a way that:

• The uploading allows users to leave the gallerypicker dialog and perform other tasks in the document, then return to see if the uploading and scaling has completed
• A progress dialogue or a message is displayed during the upload and scaling. The action can be cancelled during the upload without side-effects.
• Disable the picker dialogue while the file is uploaded and scaled to prevent the user to cancel the action involuntary.

After consulting the internal hippo development list, we have received some directives of how to solve the background processing issue by using the workflow mechanism .

• A workflow should be created with handles the scaling of the image by delegating it to the GalleryProcessor

• The workflow should be invoked by way of getWorkflowContext(Date
  date). When a workflow is invoked that has been obtained in this way, it will
  actually be scheduled as a job and run at a later time.

• It does need to run within the context of the repository then, without any dependence on wicket and other cms dependencies. There might be other problems having to do with serializability, i.e.
  workflows are also available over RMI so serialization should be
  handled. (things like the client/server workflow manager may need to learn how
  to transfer InputStreams, for instance)

• The new workflow should then also offer an api to do synchronous scaling of individual images in the image-set, IMO, to be used when the user is interactively editing the imageset.