Uploader, the strange case of when Cancel is Done

[Eli Cochran]

Michelle,
Thanks for your question. I've had some more time to think about it  
and had a nice conversation with Colin about what I'm trying to do here.

I've decided that I'm just over-engineering the damn thing. First, we  
don't need to invent anything new, we don't need actions. But secondly  
that we also don't need to push this functionality into events either,  
or into the Uploader at all. Since the implementor needs to define  
this functionality anyway let's leave it to them to attach the events  
using standard jQuery event attachment [$(".fl-uploader- 
cancel).click("...")].

One up shot of this, which is solves my other problem is that instead  
of one button for cancel that is smart about the state of the  
Uploader, I'll have two buttons, one for the before and another for  
the after state. Again, what they do, is up to the integrator.

Thanks,
Eli

On Mar 13, 2009, at 7:03 AM, Michelle D'Souza wrote:

> Another question from me too. :)
>
> On 13-Mar-09, at 12:18 AM, Eli Cochran wrote:
>>
>> So I defined two actions:
>> - options.actions.done
>> - options.actions.cancel
>>
>
> I'm interested in the 'actions' section of the options. How is this  
> different from using an event? Does the framework do something I  
> don't know about with 'actions'? I would likely have done something  
> like this:
>
> options: {
> 	events: {
> 		onDone: null,
> 		onCancel: null
> 	}
> }
>
> Thanks,
>
> Michelle
>
> ------------------------------------------------------
> Michelle D'Souza
> Software Developer, Fluid Project
> Adaptive Technology Resource Centre
> University of Toronto
>
>
>

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090313/1be76ce3/attachment.html>