On 4/26/13 2:24 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
> Ok, since you apparently don't trust my expertise on this, and I care
> too much about this project to just let you figure this out when
> things start breaking, an analysis of the current solution and why I
> think 'goog.events' is superior:
Hi Erik,
Thanks for the detail analysis. That was very helpful and the kind of thing
I was looking for. It is not an issue of trust, it is about having
objective criteria recorded somewhere so we can look back later and know why
we made a decision.
I should have provided my line of thinking earlier. It is this:
The top browser market share looks like this based on [1].
Microsoft Internet Explorer 8.0 23.23%
Microsoft Internet Explorer 9.0 20.62%
Firefox 19 13.55%
Chrome 25.0 13.42%
(everything else is below 10%)
I think we can all agree that IE8 is on a downward trend. Of the remaining
(IE9, FF, Chrome), it appears that they have all standardized on DOMEvents.
Is this not true? Because if they have, then the code minimalist in me
would want to just use the built-in browser code and handle IE8 as a
polyfill. If they haven't standardized, then you can stop reading and check
in your changes.
>
> The current solution is actually 3 solutions: the one in
> 'HTMLElementWrapper', the one in 'EventDispatcher' and finally
> 'IE8Utils'. The first wraps DOM events, the second is a custom
> solution to manage non-DOM events, number 3 combines both approaches.
> What if someone want to write a component that extends
> HTMLElementWrapper but wants to use a non-DOM event? Wait, that is
> what already happens in 'Application'. There you have to override
> 'addEventListener' (without the JSDoc indicating you did), basically
> creating a fourth implementation.
>
> 'removeEventListener' is only implemented on instances of
> 'HTMLElementWrapper' meaning there is no way to remove event listeners
> added through the other 3 implementations.
>
> 'createEvent' uses 'document.createEvent' and 'document.initEvent',
> both which are deprecated by Mozilla [1], not exactly improving the
> future-proofness of the current solution. All events are created with
> both 'canBubble' and 'cancelable' set to false, without the ability to
> change this. The IE8 implementation - using
> 'document.createEventObject' - is not separated out like other IE8
> specific implementations.
>
Good point about other objects dispatching events that don't wrap DOM
objects and that the IE8 impl is not fully separated out, but I think you
are misinterpreting the other code you found, especially what is going on in
Application. My bad for not putting comments on that. Regarding
createEvent, isn't it true that for the non-IE8 browsers listed above you
can just call "new Event()" and use custom event "types" (like "initialize"
or "idChanged") or is that still not standardized? If that's not
standardized, then again, you can stop reading and check in.
> The 'IE8Utils.EventMap' is by no means complete. It also uses the 'on'
> prefix that is never added to the event type specification anywhere in
> the framework. This means all IE8 events fail the 'EventMap' test and
> are handled as custom events...
Yup, that's why I am now in favor of using goog.events for IE8.
>
> I could go on (trust me?), but I think the above is enough to make my
> case and I don't feel like spending a lot of time on this anymore.
>
> TL;DR: there are currently 4 (!) possibly conflicting and certainly
> confusing partial implementations of an event handling system. I
> suggest we replace this with one thoroughly tested and real world
> proofed solution, which I already implemented and is ready to go.
So there isn't 4, but there is 3. I could be wrong, but I didn't think the
dividing line was whether you were sending a DOM event or not, but whether
you were wrapping a built-in object that could dispatch events. Then the
three are:
1) wrapped built-ins (Label, Button, and even HTTPService)
2) other stuff (Timer appears to be the only example right now)
3) IE8
The code-minimalist, pay-as-you-go philosophy says that folks who don't care
about IE8 and build an app entirely out of pieces in #1 (which is totally
possible and probable, especially for apps intended for mobile) shouldn't
need to carry goog.events around.
I think goog.events is a bit heavy for #2 since it doesn't need
bubble/capture, but I'm now ok with using it there for now. Maybe we'll
find a smaller implementation someday, maybe not.
And I'm now all for using goog.events for #3.
But again, this all presumes the browsers other than IE8 have standardized
on their event API which means:
A) use of "new Event() instead of createEvent/initEvent
B) I can pass any string I want into "new Event()"
Thoughts? And thanks again for taking the time.
[1]
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2&qpcustomd=
0
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
