Re: Detecting and Creating Events

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.

About canDispatch, if an implementation performs an internal test,
actually dispatching and returning the event, then it would be
trustable. However, creating and dispatching an event would has
obvious side effects.

[...]

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

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

Sure. I don't care either way.

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

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

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.

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

There isn't any good way to do that and the "general purpose"
solutions I've seen are frankly awful. If anyone has a solution for
this, please post up for review.

Regards,

Garrett

Received on Sunday, 23 August 2009 19:55:26 UTC