Re: [DOMCore] Making event initializing easier

On Fri, Mar 4, 2011 at 2:25 AM, Anne van Kesteren <annevk@opera.com> wrote:
> In general I would like to refrain from introducing new features at this
> stage, but the initXXXEvent() pattern is problematic and it would be nice if
> we can avoid it for all new event interfaces. It is problematic for these
> reasons:
>
>  * You have to remember and set all the arguments each time.
>  * It makes extending existing event interfaces with new features
> impossible.

Agreed.

> If we can introduce a new design now we can avoid proliferating new event
> interfaces with initXXXEvent() and slowly move away from that design.
>
> If we indeed introduce objects into our APIs and I start to think that would
> make sense I think the simplest approach that could possibly work here is to
> overload initEvent(). In addition to its three argument version it would get
> a version that accepts just one argument, an object. From this object
> property values are queried to set values on the event. E.g.
>
>  var e = document.createEvent("CustomEvent")
>  e.initEvent({"type":"custom", "details":{"hello":"world"}})
>  document.dispatchEvent(e)

I'd prefer something even more direct, moving away from "create*"
methods entirely and using "new" instead. E.g.:

var e = new CustomEvent({ type: "custom", details: { hello: "world" }});
someNode.dispatch(e);

Regards

> These are the reasons why I prefer this design over settable attributes or a
> constructor-based approach:
>
>  * It is a very minimal change from the existing model. The existing model
> is not great, but it is what we have and deviating away from it far for a
> feature mostly used for debugging is not worth it. Even if not just used for
> debugging the above is not much more complex than what libraries offer.
>  * With settable attributes it becomes a little messier to also unset
> several flags at the same time. You would always want to unset the "trusted
> flag" for instance. (An alternative would be to not allow initializing
> already dispatched events (possibly scoped to trusted events), but that is
> not what implementations do.) Depending on the outcome of the other thread
> we might also want to reset the "stop propagation flag", "stop immediate
> propagation flag", and "canceled flag" here. Having these as side effect of
> initEvent() makes sense. Having them as side effect of setting the offsetX
> or type attribute makes a lot less sense.
>  * In order for the constructor-based approach to work well you would want
> this kind of object-approach as well. Otherwise you have the same issues
> with having to remember all the arguments and making extensibility
> difficult. It seems therefore better to first experiment on a somewhat
> smaller scale (just initEvent(object)) than introducing constructors all
> over.
>
> Interested to hear what you all think!
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>

Received on Wednesday, 9 March 2011 14:59:11 UTC