Re: Detecting and Creating Events

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.  You could suggest a clarification for the text and then you
don't need to add all those new methods.

The DOM Level 3 Editor's Draft says:

> > canDispatch   introduced in DOM Level 3

> > Tests if the implementation can generate events of a specified type.

> > @@ what is the use case for this? Perhaps to test if an implementation
> > supports a particular event, such as an event from an uncommon language,
> > or a custom event?  Or what does the "implementation can generate" mean?
> > -Olli

> > namespaceURI of type DOMString
> >    Specifies the Event.namespaceURI of the event.
> > type of type DOMString
> >    Specifies the Event.type of the event.

> > Return Value

> > boolean: true if the implementation can generate and dispatch this event
> > type, false otherwise.


> 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?

Event names now need to be parsed to extract the interface name and the
event type name (currently, that isn't required).  At least have them as two
separate parameters if you want to do this.

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).

There's nothing to stop you assigning additional properties to the Event
object after you've initialised it.



> 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.

-- 
Stewart Brodie
Software Engineer
ANT Software Limited

Received on Thursday, 20 August 2009 11:33:16 UTC