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