RE: Faking host objects

Ooops, I did quit the list by mistake.

 

 


De : Marcos Caceres
Envoyé : ‎1‎ ‎janvier‎ ‎2013 ‎22‎:‎20
À : François REMY
Objet : Re: Faking host objects



Hi François,
Is it cool if we move this discussion to the list?  


--  
Marcos Caceres
http://datadriven.com.au



On Tuesday, 1 January 2013 at 20:18, François REMY wrote:

> I did investigate the event issue a bit. It seems like it’s possible to create custom events.
>  
> var e = document.createEvent(”CustomEvent”);
> e.initCustomEvent(”eventname”, true, false, {...});
>  
> then you can really customize e with any property you want and use it in dispatchEvent. I tried changing the prototype chain via Object.create, but IE did not like it. However, Chrome has no issue changing the __proto__ to another one create using Object.create and the CustomEventPrototype object. I guess changing the __proto__ doesn’t change the object identity, at least in Chrome.
>  
> If we want a solution that works cross-browser, we may want to redefine the properties on the CustomEvent object itself, but we may create a special proto chain on browsers that supports __proto__.
>  
> François
>  
>  
>  
> ----------------------------------------
> > Date: Mon, 31 Dec 2012 14:20:18 +0000
> > From: w3c@marcosc.com (mailto:w3c@marcosc.com)
> > To: francois.remy.dev@outlook.com (mailto:francois.remy.dev@outlook.com)
> > Subject: Re: Faking host objects
> >  
> >  
> >  
> > On Monday, December 31, 2012 at 2:06 PM, François REMY wrote:
> >  
> > > Seems good. One question though: What’s the difference between reusing the native “addEventListener”/”dispatchEvent” and simply reimplementing them? You get some values defined on the “event” object?
> >  
> > That was the original idea… but now, no: you don't get anything anymore because CustomEvent.detail prevents the browser from touching the author-defined event (MIDIEvent) itself.
> >  
> > I'm slowly coming to the conclusion that using the native one (i.e., my "x-eventDispatcher") is probably worst, tbh.
> >  
> > The pro of using the native one is that it is less code to carry around (i.e., just leave it to the browser). But, again, the con of the native one being that it strips off any properties you add to an author-defined event (hence my exploiting of CustomEvent.details).
> >  
> > Having said that, writing an DOM conforming event dispatcher is about 50 lines of code. This is weighted against having to wrap everything.
> >  
> > This is something for the group to also consider - as EventEmitter could just be something our group makes available. In the past, I've filed a bug on DOM4 requesting EventEmitter to be something the DOM provides natively. It's infinitely useful.
> >  
> > Ps: we can replay this on the list if you would like.