I read up a little on Google Closure Events. I was hoping to find some information on why it takes that much javascript to implement a brand new event model when it appears (at least from my perspective) that the only rogue browser is IE8.
I think I'm going to forge ahead with my custom approximation of events in IE8 and maybe I'll discover why Google Closure Events are better. I would rather use a DOM Events API surface since that's what AS has and folks are used to. On 3/30/13 9:15 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > Hi, > > From [1]: "Closure Library provides the advantage of a consistent > event model that works the same way in all browsers." > > And the GC Compiler takes care of any overhead, it can very > efficiently re-compile "goog" based Javascript. More so than "manual" > JS like FlexGlobals. And we're using the GC Library anyways. > > I plan to look at the "insides" of FlexJS Javascript code next week, > see what I can come up with. Maybe start a branch, we can do that > easily now in git :-P > > EdB > > > > On Sat, Mar 30, 2013 at 5:00 PM, Alex Harui <aha...@adobe.com> wrote: >> >> >> >> On 3/30/13 7:54 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >> >>> I left out FlexGlobals on purpose, I plan to bring the Google Closure >>> way of dealing with events to FlexJS. The GC way is not dependent on >>> DOM based events and fits very snugly with the way Flex handles >>> events. >> BTW, do we need a DOM event for MouseEvents? >> >> Also, I was going to work on IE8 compatibility soon. Does Google Closure >> events work well on ie8? How much overhead is there for using it? >> >> -- >> Alex Harui >> Flex SDK Team >> Adobe Systems, Inc. >> http://blogs.adobe.com/aharui >> > > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
