Re: Can Dispatch canDispatch()?

On Thu, Aug 27, 2009 at 9:50 PM, Sean Hogan<shogun70@westnet.com.au> wrote:
> Garrett Smith wrote:
>>
>> On Thu, Aug 27, 2009 at 12:28 AM, Sean Hogan<shogun70@westnet.com.au>
>> wrote:
>>
>>>
>>> Actually, I've changed my mind on canDispatch() and I would propose we
>>> keep
>>> it (but maybe change the name to hasEvent() as suggested by Garrett
>>> Smith.)
>>>
>>>
>>
>> That wasn't a name change proposal; it was a straw man. really,
>> anElement.hasEvent wouldn't tell a whole lot about the event.
>>
>> canDispatch is something that reminds me very much of hasFeature. It
>> operates on a document level and portends what feature is supported.
>> Method hasFeature never was trustworthy, and so I think that
>> canDispatch would have the same tendency. It is too far removed from
>> the actual problem.
>>
>>
>>
>
> Yes, it is like hasFeature, but there are a few differences which may
> mean vendors try to keep it trustworthy:
>
> - basically hasEvent() is finer grained. It is more like <code>if
> (document['addEventListener'])</code>
>   than <code>if document.hasFeature("Events", "3.0")</code>.
>
> - if hasFeature() gives a negative, that doesn't give you any
> information about how much of the spec is missing. So devs don't bother
> checking it. So vendors don't bother keeping it valid.
>   If hasEvent() gives a negative then you just use your fallback. If
> it is a false negative then you also lodge a bug report with the vendor.
>
> - if hasFeature() gives a false positive, unless it is a major omission
> it seems pointless (and petty) to complain to the vendor (about the
> false positive).
>   If hasEvent() gives a false positive then you could justifiably
> lodge a bug report with the vendor and not bother with work-arounds.
> This would put the onus on the vendor to report the right value.
>

Explanation of what the proposed - EventTarget - method - hasEvent -
would potentially do, before weighing pros and cons.

1. document.body.hasEvent("click")
2. document.documentElement.hasEvent("submit")
3. document.forms[0].hasEvent("focus")

1. true  -- the body will fire click
2. false -- this element does not fire "submit" events
3. true  -- this element can, if it has a tabIdex, fire focus events

The method name "hasEvent" is probably best renamed to "firesEvent".
The documentElement does not "have" a "submit" event, but a "submit"
event could bubble up to it (in a compliant implementation), so, it
could catch a submit, and in that case, would it have it? "hasEvent"
is a bad name.

The name "firesEvent" tells what the eventTarget will do, not about
the event. This is a limitation of the feature and that is indicated
in the method name.

Pros:
  * easy to use.
  * provides information about the object it is called on.

Cons:
* does not provide detail about an event:
  - does it bubble?
  - does it have a timeStamp? If so, what is that?
  - what is the relatedTarget? (consider opera's implementation of
event.relatedTarget for "submit" event).
* might return false positives. I remember "oncontextment" in
document.body being reported as true in an early version of Opera 10a,
where the event was reportedly experimental (from a reliable source at
Opera).

For each new event, implementers must consider "firesEvent", to make
sure that it would not return false positives, breaking working pages.

An EventTarget "firesEvent" method would provide a very simple,
standard check directly on an object.

The alternative to that would be something along the lines of creating
and dispatching an event.

Going with the suggestion of dispatchInitedEvent:

=====================================================
----------------------------------------------
  interface EventTarget {
    boolean dispatchInitedEvent(in DOMString type,
                                        in Object
options);
------------------------------------------------
dispatchInitedEvent

Dispatches an event onto the event target on which this method is called.

Parameters
type - of type domstring
    The event type to be dispatched.

Return Value
boolean - Returns false if the default action as prevent (as if a
callback called "preventDefault" to stop it).

=====================================================

Usage 1:
A program could use dispatchInitedEvent to fire events and check to
see if they fired.

Usage 2:
A test framework could use dispatchInitedEvent to create and dispatch
events on objects.

Pro:
Detailed information about the event is provided in the callback.

Pro: extensible. The current initXXXEvent methods tie the method name
to the sub-interface. For every new event that is created, now, an
initXXXEvent method must be created. With dispatchInitedEvent, a new
Event interface does not need to create its own initXXXEvent. Programs
can use dispatchInitedEvent in the Event super-interface, passing the
interface as the type.

Pro: simple interface. The current initXXXEvent methods use long,
unmemorable parameter lists. dispatchInited event provides a simpler
interface.

Con:
Side effects from the event firing (which could trigger other callbacks).

Harder to code than simple - firesEvent(type) - (more plumbing).

Recap two proposals:
1) firesEvent(type) - boolean. returns true if a target can fire an
event matching - type -.

2) dispatchInitedEvent(type, options) - boolean.  dispatches an event
on a target. Returns false if a callback called prevented default
action (as if by "preventDefault").

Garrett

Received on Friday, 28 August 2009 07:01:56 UTC