Re: Detecting and Creating Events

On Thu, Aug 20, 2009 at 4:23 AM, Olli Pettay<Olli@pettay.fi> wrote:
> On 8/20/09 8:18 AM, Garrett Smith 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?
>>
>> Proposal: add a "hasEvent" method to EventTarget:
>>
>> EventTarget {
>>   boolean hasEvent(in DOMString eventType)
>> }
>>
>> This allows script to call the target's "hasEvent" method to see if
>> the event is (claimed to be) supported.
>>
>> var hasFocusIn = false;
>>
>> if(typeof el.hasEvent != "undefined") {
>>   hasFocusIn = el.hasEvent("domfocusin");
>> }
>>
> This has the problem that browser may not know what additional events
> extensions or plugins can fire.

If the plugin supports EventTarget, including this proposed feature,
then hasEvent could be called.

A real problem is that it doesn't tell you if the event will bubble.
This is a problem with proprietary or legacy events like submit
(submit was non-standard, at the time).

>
>
>> 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 agree a method like this would be very useful, but it could
> be easily implemented in a script library.
>

Really? How does a program pass a - pageY - property to
initMouseEvent? What about explicitOriginalTarget? The method
signature does not accept those.

Method initXXXEvent accepts a list of Event properties. That list, as
long and unmemorable as it may be, is fixed. Event properties that are
not recognized, be they proprietary as - pageY - or be they new
additions to the standard (whatever they may be) are not an option.

Even if all that a program desired was to create events that are
currently creatable, using the somewhat limited and clunky API, it
would not be that easy, probably not less than 300 LOC. I'll take the
suggestion that a "script library" is needed as acknowledgment that
the API is too painful to use. That pain should be addressed. There
isn't a good reason that creating an event needs to be that hard. The
reason it is so painful is due to the design of the API.

Native code could take that options map and would make creating events
easier and simpler. I don't want to bog down my pages with an event
creation adapter library and I can't for the life of me remember what
the seventh-argument to initMouseEvent is. I see the second is
"canBubbleArg". Which mouse events do not bubble?

However, even if all a program wanted was to create events, it the
approach relies on initXXXEvent. It doesn't seem to allow for creating
new event properties and event types, such as progress event.

The initXXXEvent methods have a fixed parameter list and that list is
coupled to the event type and version -- not extensible.  Each method
type is tied to the event type. That means that for new event types,
it is necessary to create a newe init<type>Event AND get all of the
parameters right. That is inflexible.

An "options" map is extensible.

> It could be useful to have
> dispatchInitedEvent(in domstring type, in Object options)

Sure, that would work, too.

> in EventTarget. (again something to implement easily in a script library)
>

No, not possible to implement with the current initXXXEvent methods.
The limited cases that are possible are not easy.

>
> -Olli
>

Garrett

Received on Friday, 21 August 2009 17:58:30 UTC