AJAX toolkit selection criteria

[Antranig Basman]

Colin Clark wrote:
> 
> I think that was "event abstraction." We're expecting most good AJAX
> toolkits should provide some model/APIs for handling events.
> 
> Colin

Now I know what this item was, I can talk about it :)

Personally I've become increasingly questioning of the value of the
various event systems in the toolkits - since they offer a 
considerable amount of dependency scattered at quite a low level,
and I wonder if they offer equivalent value.
In particular, many of the event frameworks (such as YUI) seem to
have most of their mighty struggle to make the "this" member 
coincide with something useful at the point of delivery. Personally
I have given up "this" in JS as a lost cause since even if sometimes
it does have a useful value, one is probably not expecting it :P

The need for a lot of the event frameworks would seem to be 
considerably mitigated by use of a more closure-based programming
style - that is, having ones handlers be simple null-arg functions
which instead of relying on "this" have all of their relevant
context closed over already.

The only thing I have seen in favour of "this" adjustment is that
it can be a way to avoid the various DOM cycle leakages on IE, but
this is a problem I am yet to really understand or see decisive 
guidelines on avoiding :P Anyone with experience and techniques for
this would be gratefully heard!

Are there any other aspects of event handling that we think could
usefully be abstracted? So far I do not seem to have run into any
of these requirements yet in the RSF widgets I have built so far,
which just use the standard DOM events - they are many of them 
admittedly quite simple things.

Cheers,
A.