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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
