Re: Detecting and Creating Events

Garrett Smith <dhtmlkitchen@gmail.com> wrote:

> On Thu, Aug 20, 2009 at 4:32 AM, Stewart
> Brodie<stewart.brodie@antplc.com> wrote:
> > Garrett Smith <dhtmlkitchen@gmail.com> wrote:
> >
> > > The inability to easily and accurately detect events is a problem.
> > > Programs want to know if an event is implemented at runtime. If it is,
> > > then the feature can be used. If not, it a fallback stratety is in
> > > order. Many new event types are being created and implemented. How can
> > > a program feature-test to see if they are implemented?
> >
> > DocumentEvent.canDispatch() would seem to fit the bill, although it's
> > not clear exactly what criteria this method is supposed to base its
> > answer on right now.
> 
> I see. It wouldn't really "fit the bill", unless it did, but since we
> don't know if it does, it must seem so.
> 
> 
> > You could suggest a clarification for the text and then you don't need
> > to add all those new methods.
> 
> No, that "canDispatch" sounds like almost as bad an idea as hasFeature. I
> learned not to trust crap like that quite good many years ago.

And yet you want to introduce another feature-detection mechanism that
doesn't work properly (too many false negatives, as you point out)?


> >> There should be a simple way to create and fire an event.
> >>
> >> interface DocumentEvent {
> >>   Event createInitedEvent(in domstring type, in Object options)
> >>   raises(dom::DOMException);
> >> }
> >
> >> In createInitedEvent, the type of event created is determined by the
> >> string arg /type/, which is a prefixed with a DOM Interface (as a
> >> string) followed by ".", followed by the event type. The event is
> >> inited with the /options/. This is a "map" of options that the event
> >> has, such as - offsetX - , - pageY - , etc.
> >
> > I don't like this interface at all, for several reasons:
> >
> > I think it unwise to add it to DocumentEvent - what about events that
> > are nothing to do with documents?
> 
> All "createXXX" methods are based off document, e.g. "createTextNode",
> "createEvent".
> 
> I'm not proposing to change that.

OK.

> > I don't like Object being passed to a DOM method. The moment you permit
> > arbitrary JS objects in a DOM API, the implementation of that method has
> > to deal with so many more problems (e.g. dealing with infinities, NaNs,
> > other objects).
> >
> 
> Infinity and NaN are numbers, not objects.

I wasn't clear.  These arbitrary objects that you are intending to pass in
to this method may have any number of properties, the types of these
properties may be infinities, NaNs, numbers, other objects, strings, etc.

Thus DOM code now has to be able to deal with these types, whereas usually
it does not because, to use my examples, infinities and NaNs are not
permitted in a DOM interface.  In all the other cases I've noticed where
arbitrary objects are passed to a DOM method, the object is only ever passed
back to the scripting engine that created it and interpreted there.


> > There's nothing to stop you assigning additional properties to the Event
> > object after you've initialised it.
> 
> Yes, there are. It's called errors. Ever try to assing to modify a
> host object? Try setting the pageX property in a few versions of
> Firefox and see what happens.

I'm not surprised.  I've found the DOM event support to be so inconsistent
between Firefox, Opera & Webkit (and non-existent in IE), that I've long
since given up trying to work out what they do and don't support so I can be
interoperable.  Sadly, just implementing the standard DOM events
specification makes you non-interoperable (due to the capturing listeners
being called in the at-target phase bug in Firefox, at least, as was
discussed here IIRC a few months ago)


> Or try using some the libraries that modify host object prototype ,e.g.
> Mootools or Prototype.js, and see how they fall apart cross-frame. I see
> also Dojo still modifies the pageX property of events, in _fixEvent.
> Modifying host objects is error-prone.

All those libraries and other well-known ones, like jQuery, tend to rely on
unreliable feature detection and built-in knowledge of different browsers
and even bugs.


> >> DOM 2 Events provides "createEvent(type)", but then required an
> >> additional step initEvent or initMouseEvent. Method initMouseEvent
> >> takes 15 arguments, none of them are memorable. It is painful to use.
> >
> > Honestly, how often does scripting wish to simulate UIEvents,
> > MouseEvents, KeyboardEvents, MutationEvents or MutationNameEvents?  The
> > only use case I can think of is a test harness that's trying to drive an
> > application under test.
> 
> A test framework is one case.
> 
> Another case is when a program needs to know if an event is supported,
> and how it is implemented (what happens when it fires).

What does it mean for an event to be "supported" anyway?    Does it mean
that the implementation may generate the event itself?  My implementation
can dispatch any events provided that the name is non-empty.  When an event
fires, it follows the DOM event dispatch procedure, as laid out in the
specification.


-- 
Stewart Brodie
Software Engineer
ANT Software Limited

Received on Monday, 24 August 2009 09:55:41 UTC