fluid infusion uploader - postParams and meta info

[Aaron Brown]

I've been testing with the uploader from fluid infusion version 0.8 for 
a few days and, having gotten all the important parts to work, I ran 
into an obstacle for my real-life use case.  I have a working solution, 
but against the chance that my use case might be generally applicable, I 
thought I'd write it up here.  If there's enough interest, it may 
warrant a minor addition or two to the uploader API.

Scenario: Server web app has been designed to accept a collection of 
file uploads all batched together into a single POST.  When the upload 
is complete, the web app sends an email notification to the "superusers" 
of the system.  This email lists the files that were uploaded as well as 
other items like user, timestamp, etc.  This is all part of the project 
specification.

With fluid uploader: The Uploader code is designed to send each file in 
a separate POST to the receiving web app, and no broader information 
about the file queue is communicated.  Thus, a simple drop-in 
implementation of the fluid uploader in the existing web app would 
produce an annoyingly high number of email notifications, each 
referencing a single file, for every time a user uploaded several files 
at once.

Solutions:
1) Add a listener function that triggers on the completion of the batch, 
causing a separate AJAX request to tell the server about all the files 
in the batch.  The web app would hold off sending any emails until it 
gets this special "I'm done! Here's what I just did..." signal.

I avoided this option on the grounds that first, limiting the number of 
extra AJAX communications is generally good and second, that it might be 
difficult to tell which files were just sent in this most recent batch 
if, for example, the user uploaded two files, then added a few more to 
the existing queue and uploaded them separately.  What is the "batch"?

2) Set a postParams option on the uploadManager and use that to pass 
whatever meta data is required.

The problem: postParams, as implemented by the uploadManager, is copied 
into the underlying swfupload object at the point of instantiation.  At 
that point, it's too early to know what files are in the queue.  All of 
my attempts to modify that parameter after the fact failed, though I 
admit that may be partly because of my unfamiliarity with jQuery and fluid.

3) Use uploadManager listeners to set post_param options directly on the 
swfupload object.

This is the solution I ended up with.  It works, but it requires diving 
straight through the uploadManager skin and messing with swfupload 
directly.  I found that the swfupload.js script includes some interfaces 
to adjust the post_params later in the game, so I made use of those to 
send my meta data.  I can provide a more complete code sample if anyone 
wants it, but here's the important part:

=======================================================================
jQuery(document).ready(function () {
   var myUpload = new fluid.progressiveEnhanceableUploader(
       ".fl-uploader", ".fl-progressive-enhanceable", {
     uploadManager: {
	// snip
     },

     listeners: {
       onUploadStart: function (fileList) {
         // flist = serialized string of all file names in queue
         myUpload.uploadManager.swfUploader.addPostParam(
           "allFiles", flist);
         myUpload.uploadManager.swfUploader.addPostParam(
           "upCount", fileList.length);
       },
			
       onFileStart: function (file) {
         var toDo = myUpload.uploadManager.queue.getReadyFiles();
         myUpload.uploadManager.swfUploader.addPostParam(
           "remaining", toDo.length - 1);
       }
     },

     decorators: {
       // snip
     }
}
=======================================================================

Here, when the web app receives a file and the "remaining" parameter is 
zero, that's the last file in the batch so do whatever actions are 
required for that batch.  This solution isn't bullet proof, so it needs 
some more work - what if the user cancels in the middle?  What if 
something breaks in the middle?  There are lots of less-than-ideal 
events that could cause that notification to not be sent, but I think 
with some extra code for other listeners that trap upload errors, it 
could be made much more solid.  Better, in fact, than the current 
(non-fluid) version which is more of an all-or-nothing kind of setup.

The ability to add/reset/modify postParams during the course of the 
upload sequence seems like it could be really useful.  This is where I 
think a quick API addition could give a more direct accessor to the 
methods in swfupload.js that manage post_params (addPostParam, 
setPostParams, etc.).



Sorry for the long-winded email.  And even more sorry if this issue has 
been covered before on the list.

  - Aaron

-- 
Aaron Brown :: aaron at thebrownproject.com :: www.thebrownproject.com