Re: [DOM3 Events] Initialising events (concerns)

Olli,

--- On Thu, 24/9/09, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:

> On 9/24/09 12:16 PM, Sergey Ilinsky wrote:
> > 1) The suggested change in the event interfaces is
> backwards
> > incompatible with DOM-Events L2 and L1.
> There is no DOM 1 Events ;)

You are right, still there is L2 ;)

> 
> > There is plenty of
> > implementations, whose are not limited by "modern
> web-browsers" and
> > include many other platforms (not even "libraries"),
> such as, for
> > example JDK [1]
> >
> > 2) The change suggested only brings minor syntactical
> sugar without
> > adding any functional value.
> The change allows extensibility. Currently we're stuck with
> the 
> properties which have been defined in DOM 2 Events, because
> we can't
> add new parameters to init methods.
> 
> Would adding new methods to Java break the backward
> compatibility?
> If we're talking about the suggested change to
> allow setting attribute values before dispatching, that
> would mean
> that Java would have to add setter methods 
> bubbles/cancelably/target/etc. Does adding new methods to
> interface 
> break backwards compatibility in Java? In C++ one could
> probably add a 
> new interface,
> which implements the setters and leave the DOM 2 Events
> interface as it 
> is now. Well, actually, one could do that in Java too.
> The currently org.w3c.dom.events.Event would stay as it is
> and
> org.w3c.dom.events.DOM3Event would have the setter
> methods.
> (ugly, but possible)

Extending API would work, but removing API methods, would not. If the existing initXXXEvent methods are not considered for removal, my concern regarding backwards compatibility becomes obsolete.

> Note, I'm not happy changing the interfaces, but the
> current 
> initXXXEvent methods are awkward and don't allow
> extensibility.

From what I understand about DOM Events architecture, the extensibility is enabled there by the means of introducing new specific interfaces to the specification. As noted below in the concern 3, these are only the DOM implementers who need this kind of extensibility. Once they are in agreement on the new interfaces, they can publish a new advanced version of specification that covers the additions.

If the goal of event initialization/dispatch easing is to help application developers to dispatch custom events into DOM, then I would like to oppose this initiative. First of all I think this would be a bad programming practice to enable (consider MVC, there you do not dispatch events into the View to be picked up by its mediators). Secondly, there is already CustomEvent interface with an event bag property "detail" that can be used to carry out arbitrary amount of contextual information.

> -Olli


> > 3) Application developer normally never
> creates/dispatches events
> > into DOM thus never facing the part of interface in
> subject. Instead
> > he only picks events up by registering a listener and
> quires event
> > object properties. Those 14 people who ever touch
> event
> > initialization methods, can create the convenience
> APIs themselves,
> > and even prototype them on objects that implement
> EventTarget
> > interface.
> >

Any comments on the third open concern are welcome.

Sergey/

Received on Thursday, 24 September 2009 11:11:08 UTC