AJAX toolkit selection criteria

[Joseph Scheuhammer]

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 
hardware-like events.

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.

-- 
;;;;joseph

"Go hang a salami, I'm a lasagna hog"
     - "Bob", W. A. Yankovic -