a fileuploaddestroy question

1,272 views
Skip to first unread message

Martin Paulo

unread,
Mar 20, 2013, 7:57:36 PM3/20/13
to jquery-f...@googlegroups.com
Hi all

Am I correct in thinking that regardless of what I bind to the fileuploaddestroy event, the ui (jquery.fileupload-ui.js) will still, in its destroy callback, neatly increment the number of files and then fadeout the element representing the file just deleted: regardless of whether the server has actually deleted it or not?

The code in question reads:

destroy: function (e, data) {
               
var that = $(this).data('blueimp-fileupload') ||
                        $
(this).data('fileupload');
               
if (data.url) {
                    $
.ajax(data);
                    that
._adjustMaxNumberOfFiles(1);
               
}
                that
._transition(data.context).done(
                   
function () {
                        $
(this).remove();
                        that
._trigger('destroyed', e, data);
                   
}
               
);
           
}
       
},

I don't want to edit this code to reflect server side failures to delete files, but it looks as though there is no other choice :(
What am I missing?

Thanks
Martin

Jim deVos

unread,
Mar 21, 2013, 5:04:48 PM3/21/13
to jquery-f...@googlegroups.com
Hi Martin,

My initial thought is that you could override the default destroy handler  when you initialize the component. , e.g:

var myDestroyHandler = function(e, data) {
 
//override stuff goes here...
 
  //don't forget to do the same housekeeping that the old handler did, since you are replacing it.
};

$
('#fileupload').fileupload({
  url
: '/foo/bar/upload.jsp',
  destroy
: myDestroyHandler
});

The docs discourage this in favor of adding an event handler,  but in this situation it might be appropriate.  Just note that in addition to calling _adjustMaxNumberOfFiles when appropriate,  it's on you to do the other tasks that destroy() was responsible for.  

We did something similar in a project I'm working on,  so that we can render an 'undelete' button instead of wiping out the row outright.

Martin Paulo

unread,
Mar 22, 2013, 2:59:57 AM3/22/13
to jquery-f...@googlegroups.com
Hi Jim

It seemed a little bit odd to me that the UI code would require either a complete function replacement (with extracts of the original method) or a rewrite.

Hmm. I wonder if I can get a reference to the original delete method and then replace it with a modified one that will call the original if need be...

BTW, I think that I know the project you are talking about :)

Thanks for the reply
Martin

Jim deVos

unread,
Mar 22, 2013, 2:49:49 PM3/22/13
to jquery-f...@googlegroups.com
Agreed,  those two solutions are a bit ham-fisted.  I like your idea for grabbing the old handler and invoking it. I just tested this out on the fileupload demo page, and it worked:


//invocation context for old handler
var thisobj = $('#fileupload')[0];

var oldDestroy = $('#fileupload').fileupload('option', 'destroy');

var newDestroy = function(e, data) {
    console.log(" greetings from the new destroy handler!");
   
//more awesome code goes here...

   
//if the delete worked on the server's end...
   
//copy data, but with blank url (don't wipe out data.url or it's gone for good)
   
var _data = $.extend({}, data, {url:null});
    oldDestroy
.call(thisobj, e, _data);
};

//replace the old handler with our handler (which may, in fact, call the old handler)
$
('#fileupload').fileupload('option', 'destroy', newDestroy);


A bit of juggling, but better than replacing the old handler outright I think.  Still, it'd be nice if there were support in the API for this sort of thing.  Maybe worthy of a feature suggestion?

Good Luck! --Jim

p.s.  I'm not stalking you, honest!  I came here looking to ask a question and saw a familiar face :-)

Jim deVos

unread,
Mar 27, 2013, 10:22:59 PM3/27/13
to jquery-f...@googlegroups.com
FYI: looks like a recent commit handles deletions much better:

Martin Paulo

unread,
Apr 13, 2013, 5:51:58 AM4/13/13
to jquery-f...@googlegroups.com
So looking at the code: in one way it's an improvement, if I'm reading the code correctly: if a delete fails, the server returns an error code, and the ui deletion isn't done. But surely the poor user is left wondering why the button click had no effect?

To get a message back to user surely there should also be something like:
.fail(function(jqXHR, textStatus, errorThrown){
                        if(jqXHR.responseText !== ''){
                            alert(textStatus+": "+jqXHR.responseText);
                        } else {
                            alert(textStatus+": "+errorThrown);
                        }
                    })

Tagged onto the end of the call chain?  Or am I missing something here?

Martin
PS: apologies for the delay in getting back to this - I've been away on a very nice holiday :)


--
You received this message because you are subscribed to a topic in the Google Groups "jQuery-File-Upload" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jquery-fileupload/9SpfNYCmgcE/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to jquery-fileupl...@googlegroups.com.
To post to this group, send email to jquery-f...@googlegroups.com.
Visit this group at http://groups.google.com/group/jquery-fileupload?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
=================================================================

Martin Paulo, BSc.
Software Developer


Tel :         +61-3-9434 2508 (Home)
Tel :          04 205 20339      (Mobile)
Site:          http://www.thepaulofamily.net

"Nobody goes there any more. It's too crowded" - Yogi Berra.
Reply all
Reply to author
Forward
0 new messages