AJAX toolkit selection criteria
clown at utoronto.ca
Thu Apr 5 14:43:40 UTC 2007
I'll take some responsibility for bringing up the issue of a requiring a
decent event handling package/module in the JS toolkit.
I am quite green with respect to JS, JS tookits, and even DOM events.
Part of my background is desktop applications, and based on that, I
was/am worried that events in core and DOM JS might be too low level.
An example of what I'm getting at comes from the desktop world where an
action event emitted from a push button. The event and its handling
abstract over the means by which the button was activated. The user
might have clicked on it with a mouse, pressed a key, or used a
on-screen keyboard to "push" the button; these details are irrelevant.
What's important is that the button was activated. Also, having that
higher-level event type allows for activating the button
programmatically, without having to worry about simulating low level
Another influence comes from SCORM and its use of JS, where SCORM
defines certain learning management events such as "SCO-start" and
"SCO-end". Briefly, a SCO-start event occurs when a student views a
learning object for the first time, and a SCO-end happens when the
student dismisses the learning object (perhaps by navigating to another
learning object). These start and end events are typically realized via
JS "onload" and "onunload" events. That strikes me as pretty
heavy-handed. For example, there are cases where one wants to split a
learning object into a number of pages for sequential delivery, and each
page will emit its own "onload/onunload" as the user goes through the
sequence. The loading/unloading of intermediate pages do *not* mean
that one learning object has ended, and another started. The learning
object is started but once, and ended when either the last page in the
sequence is dismissed, or the user abandons the sequence. SCORM,
however, can't handle this, given the way that SCO-start and SCO-end are
implemented. The start and end events strike me as useful higher level
events that ought be independent of the exact way they are realized.
But, as I said, I'm pretty new to all of this, and I'm not sure that
such event abstraction in possible in JS. Time will tell.
David Bolter wrote:
> With browser events generally, I think any toolkit is probably going to
> want to provide a developer with wrapper API for browser normalization.
That's a very good reason for a common event package. Were that all
browsers simply implemented the W3C spec.
> I hate IE.
Shhhhh. You might hurt its feelings.
"Go hang a salami, I'm a lasagna hog"
- "Bob", W. A. Yankovic -
More information about the fluid-work