AJAX toolkit selection criteria

[Antranig Basman]

These are two interesting, and different directions :P

David Bolter wrote:
> This function does some event normalization including some handy key 
> event normalization etc.

Yes, I have heard that when it comes to detecting different kinds of key events
the browsers are extremely irregular - this sounds like a very profitable 
area to palm off onto one of the libraries - or at least onto PART of one of the
libraries! (i.e. at least use its mapping scheme if not all of its event model).

Joseph Scheuhammer wrote:
> 
> 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.

Well, such things are actually massively easier in JS than is generally
suspected - the layer of Java-ness shoved on top of it at the late 
stage tended to obscure its riches. For example, I seem to be able to
get away with the following dozen or so lines of JS (from RSF.js) for 
the eventish needs I have met so far (the "exclusion" system is 
suppressed for clarity)

  function getEventFirer() {
    var listeners = {};
    return {
      addListener: function (listener) {
        if (!listener.$$guid) listener.$$guid = addEvent_guid++;
        listeners[listener.$$guid] = {listener: listener};
        },
      fireEvent: function() {
        for (var i in listeners) {
          var lisrec = listeners[i];
          lisrec.listener.apply(null, arguments);
          }
        }
      };
    }

This will deliver any number of arguments to listeners of any signature, and
seems to work in any even slightly reasonable browser. The point is that
rather than having any particular listener/event system imposed on the 
listeners, you can simply use whatever signature they already have - a very 
RSF-like approach to the client-side :P