Re: Dropping (or deprecating) event initialization methods

On 9/18/09, Morten Barklund <morten@barklund.dk> wrote:
> Hi,
>
>
>  >   * adding attributes to a parent interface, like UIEvent, would mean
>  >     that the intuitive argument order could not be kept in the child
>  >     interface's method
>
>
> I find this to be the biggest problem.
>
>  If arguments of init-methods should be in order of attributes from each of
>  the interfaces in the inheritance chain in inheritance order, you
>  essentially either have to settle with the interfaces currently available
>  ("for all eternity") or change the argument order every time an interface
>  is changed and breaking backwards compatibility - or once and for all
>  change the initialization pattern used.
>
>
>  > I suggest that we dispense with this pattern, and instead make all of
>  > the attributes that these initializer methods would set writable.  If
>  > assigned to during event dispatch, an exception would be thrown.
>

The pattern can't be forgotten. It is in widespread use. The existing
methods are not extensible, but they can't be just removed.

The existing API can be refactored to a more extensible design, while
preserving the (baroque) initMouseEvent.

This makes it easy for scripts to transition to the new methods using
feature detection.

>
> I see two combinable solutions. Either create initMethods that take
>  dictionaries of attributes like:
>
>  document.initMouseEvent({target: foo, relatedTarget: bar});
>

That is what I proposed. Here:-
http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0164.html
 * createInitedEvent
 * hasEvent

The discussion had several useful comments from Olli Pettay who
suggested/helped elicit:
 * dispatchInitedEvent
 * firesEvent

Method createInitedEvent would take an object and, for each property,
set a value on the event.

var ev;
// Check to see if the method is supported
if(obj.createInitedEvent) {
  ev = obj.createInitedEvent({ target: document, clientX: 10,
relatedTarget: document} );
  if(ev.relatedTarget !== document) {
   // New feature not fully supported.
  }
}

>  And/or make attributes settable during the event initialization phase and
>  lock them down once the event is dispatched as Cameron suggests. Both are
>  tricky ways to implement in some languages and easy in others. Using the
>  dictionary approach is though possible with the current possibilities in
>  the Web IDL language, but it is a foreign concept still.
>

The problem with allowing properties to be settable is that it
introduces an incompatibility. This is bad for two reasons:
 * implementors have to immediately change so they can stop throwing errors
 * developers will use the feauture, testing maybe three or four
latest browsers and causing errors in implementations today.

>  Actually one could also argue, that the order of arguments should be
>  implementation specific, as some languages do not have the same
>  limitations (e.g. python with named arguments), but this is of course
>  necessary given the Web IDL specification language selected.
>

The order that properties are added to an object does not matter in
ecmascript (though it can affect for-in enumeration). The neat part of
the proposal is there are a set of defaults that the caller doesn't
need to specify.

>
>  > I suppose some web content would rely on these methods currently, but I
>  > would guess it's not much.
>
>
> Neither would I. I think the primary use case for this (in JavaScript) is
>  for unit testing, where scripted event creation is needed to test
>  interactivity.
>

Another case: A program that wants to make a feature test, so it can
make a strong inference of what will happen when an event fires at a
certain target, under certain conditions. To determine what will
happen when an event fires, the program creates and dispatches the
event on the target.

Garrett

Received on Friday, 18 September 2009 17:47:34 UTC