Alex,
>> I'm not going to debate on the basis of a 6k difference, honestly. 6k
>> is not a 'hit'. 6k takes not even half a second to download... on a
>> 128kb modem! On an average broadband connection (I don't believe I'm
>> actually taking the time to type this) it takes around 1/100th of a
>> second.
> We said that very thing for current SDK and Hello World apps. We said it so
> often, that HelloWorld is now well over 200K. So, I am probably overly
> sensitive to this kind of rationale, but I don't like increasing the size of
> things without truly understanding what we're getting for it.
You have to trust me on this, because I'm not willing to spend a lot
of time detailing all the reasons why this is a good idea. I've spend
a large part of my carrier building and maintaining large JS
frameworks and honestly, we need all the help we can get. The Closure
Library offers many things that this project needs, such as a solid
event handling foundation, allowing us to focus on building cool
components instead of re-inventing the wheel for the internals.
>> What we get for this is a really clean framework (no IE8Utils,
>> FlexGlobals etc.).
> FlexGlobals is independent of goog.events isn't it?
No, 'createProxy' is used extensively in event management in the
pre-'goog.events' version.
>> We don't have to spend time on fixes for the
>> 'roll-your-own' solution.
> How do you know it needed fixing?
Because there are all kinds of 'utils' classes and customised browser
dependant paths in the code that are neither inclusive nor generic.
>> We have a fully enterprise tested and
>> real-world proofed event system that does not depend on DOM elements.
>> It maps well to the Flex event system users and developers are used
>> to.
> I think I'm seeing "dispatchEvent('eventName')" instead of
> "dispatchEvent(new Event('eventName'))" Is that correct or an error? If
> correct, how does user written AS code that uses "dispatchEvent(new
> Event('eventName'))" work?
Both work. I never touched the AS code. 'goog.events' runs the vanilla
FlexJSTest_again example. The string argument option was added to
simplify the framework: no more 'create event before adding it as an
argument' needed.
>> Please take a look at the code, I spend some time with the framework
>> itself and cleaned it up a bit as well.
> Thanks for cleaning up the framework, but it made reading the code harder
> because the commits were not atomic. The changes for goog.event seem to be
> mixed in with lots of whitespace and other changes. The diffs are too
> large.
Frankly, the framework was (already) getting sloppy. Too many
copy-paste errors, too many variables declared improperly or not at
all, ending up in the global namespace. Too much of the code wasn't
properly formatted, making reading difficult to read and potentially
inviting/causing errors. Instead of trying to fix everything manually
I turned to the Closure Linter and JSLint for help. The former
strongly suggests specific whitespace handling, hence all the myriad
changes in that. The latter requires very strict 'block' bracketing,
adding to the changes. They did help me catch so many issues though,
so I think it was worth it. For this particular contribution it might
be easier to actually read the code than it is to read the diffs, if
you want to see what's changed ;-)
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
