Uploader, the strange case of when Cancel is Done

[Eli Cochran]

Another great question.

I think that I could use the regular event system. Yes, there is some  
advantage there to have the DOM element fire an event, providing a  
mechanism for other parts of the component to respond to the "event".

I invented something different because these are little different than  
the way we usually use events, or at least the way events are used in  
the rest of the Uploader. Currently none of the other DOM elements in  
the Uploader directly fire an event, they have a function bound to  
them instead. That function may fire an event down the line but that  
feels very "internal"; if that makes sense.

I'll play around with using an event, actually a combination of events  
and listeners. So the integrator instead of defining an "action" for  
the button, would be defining a listener for the event that the button  
fires off. It's just a different (and slight foreign, unless your a  
Fluid developer) way to think about the way DOM elements respond to  
events. (And here I'm talking about DOM events, not our events.)

- 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/deb965c6/attachment.html>