You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Erik de Bruin <er...@ixsoftware.nl> on 2013/04/24 20:10:24 UTC
[FalconJX][FlexJS] committing?
Alex,
I see you're doing some committing. I have the 'goog.events' based
framework done for a previous version of FlexJS and I'm not waiting to
update it to the latest and greatest.
Do you have any more commits planned for 'today'?
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>> Sounds like you're currently not interested. Too bad. I'll leave the
>> branch on the public repo in case you change your mind.
> Erik, I really appreciate the time and energy you've provided to Apache
> Flex. However, it feels like every time I question a contribution, you
> threaten to quit. The vast majority of the lines of code you have submitted
> are in the repo. Of the 100's of lines of changes in the goog.events
> branch, I am only questioning a small percentage of them.
Well, the feeling is mutual, it's like every time I try to make a
contribution to FlexJS, you tell me it's not what YOU would do if
you'd worked on it. That's not a review on technical merits, that's
personal preference. Technically, the 'goog.events' donation (which is
more than purely the implementation of 'goog.events') is valid - as it
faithfully plays back the FlexJSTest_again example - and it improves
and simplifies the framework. It will also simplify component and
framework implementations going forward. The only cost is 6k increase
of the final deliverable...
> We are supposed to work together and to me that means that we have to be
> willing to accept reviews. I think I am keeping the review on a technical
> level as we are supposed to at Apache. If you feel personally attacked then
> please point out what language I am using that feels like an attack and
> accept my apology.
I accept reviews, certainly. And if a valid technical point is made,
I'd even consider reverting, as is the Apache Way (tm). But I haven't
yet heard a technical point. If it boils down to it that in this day
of universally available broadband connections a one time 6k increase
in the size of the deliverable is considered a "technical issue",
well... that makes me feel like quitting. Nobody is fighting a highly
unoptimised 8k CSS file that was just added to the release
deliverable, because it adds functionality that we like and want. Why
would we block that based purely on the fact that it adds 8k?
> It has gotten to the point where I feel like I should never review your
> contributions and just let you check in anything you want. Maybe that's
> what Apache means by "community over code", but that doesn't feel right to
> me.
"Community" means compromise. That means that you sometimes will have
to accept code and contributions that differ slightly from - or may be
totally opposed to - what you would produce. Working together involves
a level of trust. I trust you when you add new features or work on the
framework. There are (should be) tests that prevent your work from
breaking something in mine. I don't question (review) every commit you
make, I don't second guess your solutions, I trust you to work on this
to the best of your ability. If you don't break it, I won't veto it. I
expect the people I work with to give me the same consideration.
>> If I decide to keep contributing to Apache Flex at all, I'll focus on
>> developing the VanillaSDK for AS->JS, a library that promises to have
>> a much shallower learning curve for application developers than
>> FlexJS.
> I hope you continue to contribute to Apache Flex, but please tell me how I
> can review your code without making you want to quit every time I disagree
> with you.
Explain to me what you mean by 'review', we seem to have different
definitions. In mine, review is 'check if it works and doesn't break
anything', with the added benefit that I keep up to date with changes
in the code. This 'goog.events' contribution offers new functionality,
improves the current implementation and generally makes life easier
for the few contributors this project has. If that's not a valid and
worthy addition to the project, I don't know what is.
If review means you'll be looking over my shoulder and question every
design decision I make and analyse the validity of every line of code
I contribute (yes, I'm overstating to make a point), it makes me lose
my motivation and since I'm doing this on my own time, as a volunteer,
for no reward other than the pleasure of doing it and the feedback of
the community, then yes, I'll threaten to quit when it happens.
Tell me where my code is wrong or could be improved and I'll gladly
use the opportunity to learn from your comments. Tell me that because
a contribution I offer is invalid purely based on a negligible
increase in output file size, and I'll object - and given I'm me, I'll
be probably be all drama queen about it, too ;-)
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJX][FlexJS] committing?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
A little out of the loop here but have been following.
> Alex, personally, I dont mind the additional 6K. I would rather take IE6&7
> support in return for it.
From what I understand there are other benefits other than just IE6+7 support right? IE7 support may be important to our existing user base ie enterprise?
> But I agree that we need to keep the file size to a minimum as much as possible.
I agree but given that a single image can be more than 6K, and the JS is most likely cached (on 2+ visit and ever better if we can host in a central location) is that 6K really such a technical issue?
If the extra 6k saves me having to debug a single client issue or saves me any time coding it's worth it IMO.
Perhaps there's another way - it there a way to make it optional?
Thanks,
Justin
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
On 4/25/13 11:53 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>>
>> Om, Justin, please read the following. If it does not change your mind
>> about taking Erik's change then we will take it since I will have then been
>> outvoted.
>>
>> 1. You only get once chance to make a first impression. Even if the app
>> starts fast when your JS or RSL is cached, the fact is that there are times
>> when it isn't cached. In early 2011, a vendor of a very popular consumer
>> desktop app was looking to port their app to Flex. They could not because
>> of the startup time for first time users. A couple of banks reported the
>> same issue trying to build consumer facing apps. I think that helped seal
>> Flex's fate. We were never able to use Flex to deliver a popular app that
>> everyone had to have.
>>
>
> I agree with almost everything you said. But any code anyone writes will
> add to the file size. Do you think that your approach will result in
> lesser code? Will it support all the use cases (other than IE6/7 support)
> that Erik wants to support by using this library? Why do we want to spend
> time on a problem that has already been solved and has been proven to be a
> very robust solution? Other than adding to file size, what are your
> arguments against it?
The way I see it, there is already a working event subsystem. There isn't
much code to it, it mostly leverages the event system in the browsers which
as far as I know is complete. Erik is proposing to replace this subsystem
with the larger goog.events even though we have no hard evidence that there
is a fatal flaw in the current subsystem. IMO, we've already spent the time
on building out a working subsystem that is lighterweight. We can't get that
time back.
So, if it ain't broke, why fix it with something larger? I wish his changes
separate the goog.events change from the other clean up he did. That way,
if we do later find hard evidence of a fatal flaw, we can either choose to
fix the current code or drop in goog.events.
>
>
>> 2. At home, I get about 80K/sec download speed. This 6K I won't feel, but
>> if we keep adding 6K just because we think it will have fewer bugs, it
>> won't
>> take long before I feel it.
>>
>
> You are implying that we are adding 6K worth of code for no reason. I am
> not sure if that is the case.
I'm not sure either. I've been asking for objective reasoning and all I'm
hearing is the prediction that the current code will have more bugs. By
this logic, maybe we should switch to Jquery. It's code has probably even
more mileage on it.
>
>
>> 3. I would like to do a poll to see if we need to support IE6 and/or IE7,
>> but will it change your opinion if we don't need to support these old
>> browsers? If not, then the votes have been cast.
>>
>
> I wouldn't want to spend time writing and testing code for IE6 and IE7.
> But if it comes as pre-packaged deal like this instance, I dont see the
> harm in using it.
Because we need to decide whether the entire Flex on JS will support IE6 and
IE7. If so, there's a lot more code we need to add to HTTPService, for
example. I haven't heard anyone ask for anything older than IE8. I'd much
rather not support it and save code and time and testing everywhere.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by OmPrakash Muppirala <bi...@gmail.com>.
>
> Om, Justin, please read the following. If it does not change your mind
> about taking Erik's change then we will take it since I will have then been
> outvoted.
>
> 1. You only get once chance to make a first impression. Even if the app
> starts fast when your JS or RSL is cached, the fact is that there are times
> when it isn't cached. In early 2011, a vendor of a very popular consumer
> desktop app was looking to port their app to Flex. They could not because
> of the startup time for first time users. A couple of banks reported the
> same issue trying to build consumer facing apps. I think that helped seal
> Flex's fate. We were never able to use Flex to deliver a popular app that
> everyone had to have.
>
I agree with almost everything you said. But any code anyone writes will
add to the file size. Do you think that your approach will result in
lesser code? Will it support all the use cases (other than IE6/7 support)
that Erik wants to support by using this library? Why do we want to spend
time on a problem that has already been solved and has been proven to be a
very robust solution? Other than adding to file size, what are your
arguments against it?
> 2. At home, I get about 80K/sec download speed. This 6K I won't feel, but
> if we keep adding 6K just because we think it will have fewer bugs, it
> won't
> take long before I feel it.
>
You are implying that we are adding 6K worth of code for no reason. I am
not sure if that is the case.
> 3. I would like to do a poll to see if we need to support IE6 and/or IE7,
> but will it change your opinion if we don't need to support these old
> browsers? If not, then the votes have been cast.
>
I wouldn't want to spend time writing and testing code for IE6 and IE7.
But if it comes as pre-packaged deal like this instance, I dont see the
harm in using it.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: [FalconJX][FlexJS] committing?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Quick reply on the stats: while on a downward trend, IE6 + 7 + 8 is > 33%.
> A cool third of all browsers. Given their generally conservative attitude
> towards upgrading software, my educated guess would be that this percentage
> is (much) higher in the enterprise.
And they are likely to standardise on a single browser.
Justin
Re: [FalconJX][FlexJS] committing?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Agreed. I'm just thinking about mobile apps. Should they really have to carry IE8 code around?
Microsoft mobile platform uses IE. Windows 7 is a blend of IE7 and IE8, Version 8 is a modified IE9 and Version 9 a modified IE10. No idea of the stats out there re versions.
Justin
Re: [FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
It's my party, I'll make it work. Do your thing ;-)
EdB
On Saturday, April 27, 2013, Alex Harui wrote:
>
>
>
> On 4/26/13 10:21 PM, "Erik de Bruin" <erik@ixsoftware.nl <javascript:;>>
> wrote:
>
> > I'm all for reducing size and optimisation, when functionality is not
> > compromised ;-)
> >
> > I'll be gone for a week, away from all but my iPad, so I'll merge the
> > 'goog.events' branch into develop when I get back.
> >
> > Thank you for the compromise, I'm looking forward to the next time I
> > have to stamp my feet and threaten to quit if I don't "get my way" ;-)
> > Or I just might decide to argue the point on technical details right
> > away, you never know...
> I'm hoping to crank out a bunch of containers next week. I think that
> means
> adding more subclasses and maybe some new properties to UIBase. I guess
> new
> classes shouldn't cause merge hell?
>
> >
> > EdB
> >
> >
> >
> > On Sat, Apr 27, 2013 at 6:00 AM, Alex Harui <aharui@adobe.com<javascript:;>>
> wrote:
> >>
> >>
> >>
> >> On 4/26/13 1:13 PM, "Alex Harui" <aharui@adobe.com <javascript:;>>
> wrote:
> >>
> >>>>
> >>>> I have no idea how to add 'goog.events' as a polyfil, as it is
> compiled
> >>>> into the code on publishing, long before we know which browser we're
> >>>> addressing.
> >>>>
> >>> It looked like we could use --externs so the polyfill doesn't get
> baked in
> >>> and then pull it in from the html after a browser check. But I haven't
> >>> tried it and I might be misunderstanding the doc.
> >> BTW, if you are not opposed to the polyfill concept and the notion that
> we
> >> might someday revert HTMLEventWrapper to proxy to the browser code
> instead
> >> of goog.events, then I'm not opposed to you checking in your changes as
> you
> >> have them and we can look into polyfills later.
> >>
> >> --
> >> 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
>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
On 4/26/13 10:21 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> I'm all for reducing size and optimisation, when functionality is not
> compromised ;-)
>
> I'll be gone for a week, away from all but my iPad, so I'll merge the
> 'goog.events' branch into develop when I get back.
>
> Thank you for the compromise, I'm looking forward to the next time I
> have to stamp my feet and threaten to quit if I don't "get my way" ;-)
> Or I just might decide to argue the point on technical details right
> away, you never know...
I'm hoping to crank out a bunch of containers next week. I think that means
adding more subclasses and maybe some new properties to UIBase. I guess new
classes shouldn't cause merge hell?
>
> EdB
>
>
>
> On Sat, Apr 27, 2013 at 6:00 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>>
>> On 4/26/13 1:13 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>>>
>>>> I have no idea how to add 'goog.events' as a polyfil, as it is compiled
>>>> into the code on publishing, long before we know which browser we're
>>>> addressing.
>>>>
>>> It looked like we could use --externs so the polyfill doesn't get baked in
>>> and then pull it in from the html after a browser check. But I haven't
>>> tried it and I might be misunderstanding the doc.
>> BTW, if you are not opposed to the polyfill concept and the notion that we
>> might someday revert HTMLEventWrapper to proxy to the browser code instead
>> of goog.events, then I'm not opposed to you checking in your changes as you
>> have them and we can look into polyfills later.
>>
>> --
>> 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
Re: [FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I'm all for reducing size and optimisation, when functionality is not
compromised ;-)
I'll be gone for a week, away from all but my iPad, so I'll merge the
'goog.events' branch into develop when I get back.
Thank you for the compromise, I'm looking forward to the next time I
have to stamp my feet and threaten to quit if I don't "get my way" ;-)
Or I just might decide to argue the point on technical details right
away, you never know...
EdB
On Sat, Apr 27, 2013 at 6:00 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 4/26/13 1:13 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>>
>>> I have no idea how to add 'goog.events' as a polyfil, as it is compiled
>>> into the code on publishing, long before we know which browser we're
>>> addressing.
>>>
>> It looked like we could use --externs so the polyfill doesn't get baked in
>> and then pull it in from the html after a browser check. But I haven't
>> tried it and I might be misunderstanding the doc.
> BTW, if you are not opposed to the polyfill concept and the notion that we
> might someday revert HTMLEventWrapper to proxy to the browser code instead
> of goog.events, then I'm not opposed to you checking in your changes as you
> have them and we can look into polyfills later.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
On 4/26/13 1:13 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>> I have no idea how to add 'goog.events' as a polyfil, as it is compiled
>> into the code on publishing, long before we know which browser we're
>> addressing.
>>
> It looked like we could use --externs so the polyfill doesn't get baked in
> and then pull it in from the html after a browser check. But I haven't
> tried it and I might be misunderstanding the doc.
BTW, if you are not opposed to the polyfill concept and the notion that we
might someday revert HTMLEventWrapper to proxy to the browser code instead
of goog.events, then I'm not opposed to you checking in your changes as you
have them and we can look into polyfills later.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
On 4/26/13 12:37 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Quick reply on the stats: while on a downward trend, IE6 + 7 + 8 is > 33%.
> A cool third of all browsers. Given their generally conservative attitude
> towards upgrading software, my educated guess would be that this percentage
> is (much) higher in the enterprise.
Agreed. I'm just thinking about mobile apps. Should they really have to
carry IE8 code around? Not just for events, but for anything else we run
into as well?
>
> I have no idea how to add 'goog.events' as a polyfil, as it is compiled
> into the code on publishing, long before we know which browser we're
> addressing.
>
It looked like we could use --externs so the polyfill doesn't get baked in
and then pull it in from the html after a browser check. But I haven't
tried it and I might be misunderstanding the doc.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
[FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Quick reply on the stats: while on a downward trend, IE6 + 7 + 8 is > 33%.
A cool third of all browsers. Given their generally conservative attitude
towards upgrading software, my educated guess would be that this percentage
is (much) higher in the enterprise.
I have no idea how to add 'goog.events' as a polyfil, as it is compiled
into the code on publishing, long before we know which browser we're
addressing.
EdB
On Friday, April 26, 2013, Alex Harui wrote:
>
>
>
> On 4/26/13 2:24 AM, "Erik de Bruin" <er...@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
>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
On 4/26/13 2:24 AM, "Erik de Bruin" <er...@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
Re: [FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
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:
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.
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...
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.
EdB
1: https://developer.mozilla.org/en-US/docs/DOM/document.createEvent
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
Actually, I'm liking the polyfill idea. Erik, can goog.events be packaged
as a polyfill for older browsers?
Oh, and I checked my ISP again. It says 1.5Mbps (small 'b') and says that a
4MB music file should download in 26 seconds. That still says I should be
getting 153KB/s, but I'm still only seeing 80KB/s on wifi.
On 4/25/13 9:18 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
> On 4/25/13 5:27 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>> Hi,
>>
>>> 1.5Mb/s or I can pay more and get 3Mb/s.
>>
>> It's probably 1.5MB/s and 3MB/s - either way time taken to download 6K is not
>> the issue.
>>
>> BTW I assume the library in question is this:
>> http://docs.closure-library.googlecode.com/git/namespace_goog_events.html
>>
>> Is does seem to have a few useful features:
>> - nice handling of "this" in event handlers
>> - Avoids circular references to stop memory leaks
>> - Bubble and capture in IE
>> - Supports IE6+, FF1.5+, WebKit, Opera
>> - Well tested and use by Google - will keep up to date with any browser
>> quirks
>> etc etc
>> - Google JS optimisation tools work with it
>>
>> Have I missed anything? Is there a google CDN hosted version of it?
> For release builds, I think it will be minified into the JS.
>>
>> How does that compare to what we currently have?
> Aha! Capture phase on IE8 may be the thing I've been missing. Although, if
> we choose not to support IE6 and IE7 (and I really think we shouldn't), I'd
> rather package up an IE8 "polyfill" so that all other browsers can use their
> native event systems.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
On 4/25/13 5:27 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> 1.5Mb/s or I can pay more and get 3Mb/s.
>
> It's probably 1.5MB/s and 3MB/s - either way time taken to download 6K is not
> the issue.
>
> BTW I assume the library in question is this:
> http://docs.closure-library.googlecode.com/git/namespace_goog_events.html
>
> Is does seem to have a few useful features:
> - nice handling of "this" in event handlers
> - Avoids circular references to stop memory leaks
> - Bubble and capture in IE
> - Supports IE6+, FF1.5+, WebKit, Opera
> - Well tested and use by Google - will keep up to date with any browser quirks
> etc etc
> - Google JS optimisation tools work with it
>
> Have I missed anything? Is there a google CDN hosted version of it?
For release builds, I think it will be minified into the JS.
>
> How does that compare to what we currently have?
Aha! Capture phase on IE8 may be the thing I've been missing. Although, if
we choose not to support IE6 and IE7 (and I really think we shouldn't), I'd
rather package up an IE8 "polyfill" so that all other browsers can use their
native event systems.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> 1.5Mb/s or I can pay more and get 3Mb/s.
It's probably 1.5MB/s and 3MB/s - either way time taken to download 6K is not the issue.
BTW I assume the library in question is this:
http://docs.closure-library.googlecode.com/git/namespace_goog_events.html
Is does seem to have a few useful features:
- nice handling of "this" in event handlers
- Avoids circular references to stop memory leaks
- Bubble and capture in IE
- Supports IE6+, FF1.5+, WebKit, Opera
- Well tested and use by Google - will keep up to date with any browser quirks etc etc
- Google JS optimisation tools work with it
Have I missed anything? Is there a google CDN hosted version of it?
How does that compare to what we currently have?
Thanks,
Justin
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
On 4/25/13 8:59 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>> 2. At home, I get about 80K/sec download speed.
> You sure? I get 10 Mb/s in Australia and in the US 10Mb/s in generally
> regarded as slow, the global average is higher than 10Mb/s.
>
> Here's some figures to go on.
> http://www.netindex.com
Damn, maybe I'm living in the wrong town? I just went to my ISP's site and
they said there are two offerings 1.5Mb/s or I can pay more and get 3Mb/s.
>
>> 3. I would like to do a poll to see if we need to support IE6 and/or IE7
> I don't think a poll would help. We need real stats not opinion - which may be
> hard to come by.
>
Here is a link [1]
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2&qpcustomd=
0
IE6 is 6%, IE7 is less than 2%. Of course, the stats for enterprises might
be different.
If we do support them, I would rather do it as a plug-in for those who don't
want to carry that code around. As I pointed out to Om, IE6/7 support isn't
just the 6K in goog.events, it is more code in HTTPService, probably
elsewhere, and more testing.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Om, Justin, please read the following. If it does not change your mind
> about taking Erik's change then we will take it since I will have then been
> outvoted.
No vote here just voicing my opinion and while I have been following the conversation I admit don't know the all the details. However 6K doesn't seem like a lot to me.
> 1. You only get once chance to make a first impression.
A slightly unfair comparison re Flex I feel, Flex apps can be 100's of KB or even a few megabytes and bandwidth has greatly improved since a few years ago. Yes caching may not occur all the time, but there's going to be more overhead in creating an HTTP connection and latency (20 -100ms/request) than downloading 6K (a few ms). If the JS files are combined and downloaded in one request it's unlikely to add any significant real time.
For instance the Adobe front page is about 120K but takes 3-4 seconds to download fully at 100 KB/s or so. Most of that (90%+) is not download time but the number of connections needed and latency and waiting for the server to respond. Even a highly optimised (and simple) site like google.com weights in at 30K but still takes 300ms at 100 KB/s or so 80% of that is latency/overhead/waiting for server.
My advice - run some tests with Charles (a reverse proxy and how I got the numbers above) and see what the effect is.
Yes I do see your point of a few K here and a few K here eventually add up and 6K may make a difference to a site under a very high load but for 99% of the time it wont even be noticed.
> 2. At home, I get about 80K/sec download speed.
You sure? I get 10 Mb/s in Australia and in the US 10Mb/s in generally regarded as slow, the global average is higher than 10Mb/s.
Here's some figures to go on.
http://www.netindex.com
> 3. I would like to do a poll to see if we need to support IE6 and/or IE7
I don't think a poll would help. We need real stats not opinion - which may be hard to come by.
Thanks,
Justin
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
On 4/25/13 1:55 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Om,
>
>> Erik, to be fair, you said that you are not interested in debating over a
>> 6k difference. I dont think Alex is raising this issue as a 'lead', rather
>> a justified technical question. As a comparison, the dojo and jquery
>> frameworks are 41KB and 32KB (minified) In these terms, 6KB of minified JS
>> seems like a big enough percentage to merit a technical discussion. Dont
>> you agree?
>
> Nope, I don't. The 6k addition is just about the entire contribution
> that the use of the Google Closure Library will add to the size of the
> deliverable, which puts us way ahead of any of the other libs.
Are you claiming that after using goog.events we can use other packages from
Google Closure and there won't be any additional size increase?
> The
> images - or SVG files - for the button states alone will contribute
> such an increase in the size of the final deliverable that the size
> increase caused by the addition of 6k of highly optimised JS is
> negligible.
>
The button states are optional. Goog.event's 6K is not.
Om, Justin, please read the following. If it does not change your mind
about taking Erik's change then we will take it since I will have then been
outvoted.
1. You only get once chance to make a first impression. Even if the app
starts fast when your JS or RSL is cached, the fact is that there are times
when it isn't cached. In early 2011, a vendor of a very popular consumer
desktop app was looking to port their app to Flex. They could not because
of the startup time for first time users. A couple of banks reported the
same issue trying to build consumer facing apps. I think that helped seal
Flex's fate. We were never able to use Flex to deliver a popular app that
everyone had to have.
2. At home, I get about 80K/sec download speed. This 6K I won't feel, but
if we keep adding 6K just because we think it will have fewer bugs, it won't
take long before I feel it.
3. I would like to do a poll to see if we need to support IE6 and/or IE7,
but will it change your opinion if we don't need to support these old
browsers? If not, then the votes have been cast.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Om,
> Erik, to be fair, you said that you are not interested in debating over a
> 6k difference. I dont think Alex is raising this issue as a 'lead', rather
> a justified technical question. As a comparison, the dojo and jquery
> frameworks are 41KB and 32KB (minified) In these terms, 6KB of minified JS
> seems like a big enough percentage to merit a technical discussion. Dont
> you agree?
Nope, I don't. The 6k addition is just about the entire contribution
that the use of the Google Closure Library will add to the size of the
deliverable, which puts us way ahead of any of the other libs. The
images - or SVG files - for the button states alone will contribute
such an increase in the size of the final deliverable that the size
increase caused by the addition of 6k of highly optimised JS is
negligible.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJX][FlexJS] committing?
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Apr 24, 2013 at 11:50 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Alex,
>
> Sounds like you're currently not interested. Too bad. I'll leave the
> branch on the public repo in case you change your mind.
>
> After Marmotinni and 'goog.events' - which combined represent a couple
> of man-weeks work - have been denied by the project lead of FlexJS,
> I'm not at all motivated to make further contributions to that
> project.
>
> If I decide to keep contributing to Apache Flex at all, I'll focus on
> developing the VanillaSDK for AS->JS, a library that promises to have
> a much shallower learning curve for application developers than
> FlexJS.
>
> It's been fun, sort of,
>
> EdB
>
>
>
I have been following all your discussions, but have not got a chance to
participate yet. Before I jump in for a bit here, I want you to know that
I greatly appreciate the hard work you guys have been putting in.
Erik, to be fair, you said that you are not interested in debating over a
6k difference. I dont think Alex is raising this issue as a 'lead', rather
a justified technical question. As a comparison, the dojo and jquery
frameworks are 41KB and 32KB (minified) In these terms, 6KB of minified JS
seems like a big enough percentage to merit a technical discussion. Dont
you agree?
Alex, personally, I dont mind the additional 6K. I would rather take IE6&7
support in return for it. Especially since it neatly abstracts the browser
differences for us. But I agree that we need to keep the file size to a
minimum as much as possible. I am not sure if this is the best place to
look for gains. Is this something you can relent for now?
Thanks,
Om
>
> On Thu, Apr 25, 2013 at 8:29 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >
> >
> > On 4/24/13 9:26 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >
> >> 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.
> > Decisions are supposed to be made on technical merit. I trust that you
> are
> > a smart and good guy, but in order to switch I think there has to be a
> > technical benefit.
> >
> > For example, you chose goog's foreach, but it couldn't handle
> break/continue
> > without try/catch wrapping and I switched to an implementation that
> doesn't
> > have that limitation. I consider that a technical decision.
> >
> > Once the technical limitations of my event implementation start to
> appear,
> > we can make a decision about whether it is easier to fix what is there or
> > switch. That's why I wish you'd separated the code cleanup from the
> > goog.events change, so we could reserve the goog.events change in case we
> > need it.
> >
> > This old post [1] indicates that goog has support for IE6 and IE7 in it.
> If
> > that is contributing to the 6K, I'd rather not carry it around. I don't
> > have as much experience you have with JS, my small sample of the
> > BrowserManager js code is all I really have to look at, but a look at it
> > shows that as you shed older browsers you can shed some really awful
> code.
> > It could be, that in 2013 when you no longer need to support IE6 and IE7,
> > that a simple small implementation like the one I have is sufficient.
> >
> > In fact, that's one reason I separated IE8 out into a separate class, so
> > folks can purge that code if they no longer need it. Recent data I saw
> > indicates that IE8 is a very small piece of the pie in the real world,
> but
> > remains a big factor in the enterprise, but probably not forever, and
> once
> > you get to IE9 and IE10, just about all the major browsers have the same
> > event API.
> >>
> >>>> 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.
> > Yes, but you would have switched to goog.bind whether we changed to
> > goog.events or not?
> >>
> >>>> 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.
> > That sounds more like style than functional technical issues. But yeah,
> as
> > a code minimalist, I'm going to try to leverage what the browsers can
> > already do instead of writing or borrowing a whole new subsystem.
> >>
> >>
> >> 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 ;-)
> >>
> > Definitely thanks for doing the cleanup. Any way we can just apply the
> > clean up and save the goog.events change in case we truly technically
> need
> > it?
> >
> > [1]
> >
> https://groups.google.com/forum/?fromgroups=#!topic/closure-library-discuss/
> > cpHlaWAkFag
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
On 4/24/13 11:50 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Alex,
>
> Sounds like you're currently not interested. Too bad. I'll leave the
> branch on the public repo in case you change your mind.
Erik, I really appreciate the time and energy you've provided to Apache
Flex. However, it feels like every time I question a contribution, you
threaten to quit. The vast majority of the lines of code you have submitted
are in the repo. Of the 100's of lines of changes in the goog.events
branch, I am only questioning a small percentage of them.
We are supposed to work together and to me that means that we have to be
willing to accept reviews. I think I am keeping the review on a technical
level as we are supposed to at Apache. If you feel personally attacked then
please point out what language I am using that feels like an attack and
accept my apology.
It has gotten to the point where I feel like I should never review your
contributions and just let you check in anything you want. Maybe that's
what Apache means by "community over code", but that doesn't feel right to
me.
>
> After Marmotinni and 'goog.events' - which combined represent a couple
> of man-weeks work - have been denied by the project lead of FlexJS,
> I'm not at all motivated to make further contributions to that
> project.
Marmotinni is still in the repo. It was not denied. I am hopeful we can
find the time to alter it a bit so that we can leverage a mustella-like test
syntax so we can test both AS and JS with one test.
>
> If I decide to keep contributing to Apache Flex at all, I'll focus on
> developing the VanillaSDK for AS->JS, a library that promises to have
> a much shallower learning curve for application developers than
> FlexJS.
I hope you continue to contribute to Apache Flex, but please tell me how I
can review your code without making you want to quit every time I disagree
with you.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Alex,
Sounds like you're currently not interested. Too bad. I'll leave the
branch on the public repo in case you change your mind.
After Marmotinni and 'goog.events' - which combined represent a couple
of man-weeks work - have been denied by the project lead of FlexJS,
I'm not at all motivated to make further contributions to that
project.
If I decide to keep contributing to Apache Flex at all, I'll focus on
developing the VanillaSDK for AS->JS, a library that promises to have
a much shallower learning curve for application developers than
FlexJS.
It's been fun, sort of,
EdB
On Thu, Apr 25, 2013 at 8:29 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 4/24/13 9:26 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>> 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.
> Decisions are supposed to be made on technical merit. I trust that you are
> a smart and good guy, but in order to switch I think there has to be a
> technical benefit.
>
> For example, you chose goog's foreach, but it couldn't handle break/continue
> without try/catch wrapping and I switched to an implementation that doesn't
> have that limitation. I consider that a technical decision.
>
> Once the technical limitations of my event implementation start to appear,
> we can make a decision about whether it is easier to fix what is there or
> switch. That's why I wish you'd separated the code cleanup from the
> goog.events change, so we could reserve the goog.events change in case we
> need it.
>
> This old post [1] indicates that goog has support for IE6 and IE7 in it. If
> that is contributing to the 6K, I'd rather not carry it around. I don't
> have as much experience you have with JS, my small sample of the
> BrowserManager js code is all I really have to look at, but a look at it
> shows that as you shed older browsers you can shed some really awful code.
> It could be, that in 2013 when you no longer need to support IE6 and IE7,
> that a simple small implementation like the one I have is sufficient.
>
> In fact, that's one reason I separated IE8 out into a separate class, so
> folks can purge that code if they no longer need it. Recent data I saw
> indicates that IE8 is a very small piece of the pie in the real world, but
> remains a big factor in the enterprise, but probably not forever, and once
> you get to IE9 and IE10, just about all the major browsers have the same
> event API.
>>
>>>> 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.
> Yes, but you would have switched to goog.bind whether we changed to
> goog.events or not?
>>
>>>> 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.
> That sounds more like style than functional technical issues. But yeah, as
> a code minimalist, I'm going to try to leverage what the browsers can
> already do instead of writing or borrowing a whole new subsystem.
>>
>>
>> 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 ;-)
>>
> Definitely thanks for doing the cleanup. Any way we can just apply the
> clean up and save the goog.events change in case we truly technically need
> it?
>
> [1]
> https://groups.google.com/forum/?fromgroups=#!topic/closure-library-discuss/
> cpHlaWAkFag
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
On 4/24/13 9:26 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> 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.
Decisions are supposed to be made on technical merit. I trust that you are
a smart and good guy, but in order to switch I think there has to be a
technical benefit.
For example, you chose goog's foreach, but it couldn't handle break/continue
without try/catch wrapping and I switched to an implementation that doesn't
have that limitation. I consider that a technical decision.
Once the technical limitations of my event implementation start to appear,
we can make a decision about whether it is easier to fix what is there or
switch. That's why I wish you'd separated the code cleanup from the
goog.events change, so we could reserve the goog.events change in case we
need it.
This old post [1] indicates that goog has support for IE6 and IE7 in it. If
that is contributing to the 6K, I'd rather not carry it around. I don't
have as much experience you have with JS, my small sample of the
BrowserManager js code is all I really have to look at, but a look at it
shows that as you shed older browsers you can shed some really awful code.
It could be, that in 2013 when you no longer need to support IE6 and IE7,
that a simple small implementation like the one I have is sufficient.
In fact, that's one reason I separated IE8 out into a separate class, so
folks can purge that code if they no longer need it. Recent data I saw
indicates that IE8 is a very small piece of the pie in the real world, but
remains a big factor in the enterprise, but probably not forever, and once
you get to IE9 and IE10, just about all the major browsers have the same
event API.
>
>>> 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.
Yes, but you would have switched to goog.bind whether we changed to
goog.events or not?
>
>>> 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.
That sounds more like style than functional technical issues. But yeah, as
a code minimalist, I'm going to try to leverage what the browsers can
already do instead of writing or borrowing a whole new subsystem.
>
>
> 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 ;-)
>
Definitely thanks for doing the cleanup. Any way we can just apply the
clean up and save the goog.events change in case we truly technically need
it?
[1]
https://groups.google.com/forum/?fromgroups=#!topic/closure-library-discuss/
cpHlaWAkFag
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
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
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
On 4/24/13 12:33 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> 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.
>
> What we get for this is a really clean framework (no IE8Utils,
> FlexGlobals etc.).
FlexGlobals is independent of goog.events isn't it?
> We don't have to spend time on fixes for the
> 'roll-your-own' solution.
How do you know it needed fixing?
> 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?
>
> 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.
>
> EdB
>
>
>
> On Wed, Apr 24, 2013 at 9:08 PM, Alex Harui <ah...@adobe.com> wrote:
>> I'm just starting to look at the diffs. But please, no variables named
>> "assing" :-)
>>
>> So do you really believe it will take more than 6K of minified code to fix
>> any bugs related to events in the current implementation?
>>
>> I'm wondering if the motivation behind goog.events is to get an event system
>> to work across a lot of older browsers we don't care about these days like
>> IE6 and IE7. If that's the case, why take on all of that code?
>>
>> I know when Adobe wrote the JS layer for BrowserManager it had a lot of code
>> paths we can probably drop if we don't have to support older browsers.
>>
>> I wouldn't want to take a 6K hit unless we really understand what we're
>> getting for it.
>>
>>
>> On 4/24/13 11:45 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>> In short (I have the branch updated and ready to be published: yes to all
>>> three:
>>>
>>> 1) it adds about 6k to the file (26k -> 32k)
>>> 2) yes, without modification, so no more IE8Utils or whatever
>>> 3) yes
>>>
>>> But I'll still publish a branch first, so you can see for yourself
>>> (there are some other changes/fixes in there as well).
>>>
>>> EdB
>>>
>>>
>>>
>>> On Wed, Apr 24, 2013 at 8:39 PM, Alex Harui <ah...@adobe.com> wrote:
>>>> I think I don't have any more commits planned on for flex-asjs unless there
>>>> is a bug fix or two. I'm planning to work on a COMPC equivalent for
>>>> FalconJX.
>>>>
>>>> My only criteria for your proposed switch to goog.events are:
>>>> 1) is the minified js for the example as small as what we have now?
>>>> 2) does it work on IE8?
>>>> 3) when writing AS code, do we still get to use dispatchEvent(new Event())?
>>>>
>>>> If the answer to all 3 is yes, then I don't have a problem moving over to
>>>> goog.events. Otherwise, I would say the status quo is the better choice.
>>>>
>>>>
>>>> On 4/24/13 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>
>>>>> BTW: the re-write/refactoring was somewhat major, so I plan to publish
>>>>> my branch first, so we can review and discuss. It will still be nice
>>>>> to have it on par with the 'develop' branch initially, though.
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>>>>> Alex,
>>>>>>
>>>>>> I see you're doing some committing. I have the 'goog.events' based
>>>>>> framework done for a previous version of FlexJS and I'm not waiting to
>>>>>> update it to the latest and greatest.
>>>>>>
>>>>>> Do you have any more commits planned for 'today'?
>>>>>>
>>>>>> EdB
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ix Multimedia Software
>>>>>>
>>>>>> Jan Luykenstraat 27
>>>>>> 3521 VB Utrecht
>>>>>>
>>>>>> T. 06-51952295
>>>>>> I. www.ixsoftware.nl
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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
>>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
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.
What we get for this is a really clean framework (no IE8Utils,
FlexGlobals etc.). We don't have to spend time on fixes for the
'roll-your-own' solution. 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.
Please take a look at the code, I spend some time with the framework
itself and cleaned it up a bit as well.
EdB
On Wed, Apr 24, 2013 at 9:08 PM, Alex Harui <ah...@adobe.com> wrote:
> I'm just starting to look at the diffs. But please, no variables named
> "assing" :-)
>
> So do you really believe it will take more than 6K of minified code to fix
> any bugs related to events in the current implementation?
>
> I'm wondering if the motivation behind goog.events is to get an event system
> to work across a lot of older browsers we don't care about these days like
> IE6 and IE7. If that's the case, why take on all of that code?
>
> I know when Adobe wrote the JS layer for BrowserManager it had a lot of code
> paths we can probably drop if we don't have to support older browsers.
>
> I wouldn't want to take a 6K hit unless we really understand what we're
> getting for it.
>
>
> On 4/24/13 11:45 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>> In short (I have the branch updated and ready to be published: yes to all
>> three:
>>
>> 1) it adds about 6k to the file (26k -> 32k)
>> 2) yes, without modification, so no more IE8Utils or whatever
>> 3) yes
>>
>> But I'll still publish a branch first, so you can see for yourself
>> (there are some other changes/fixes in there as well).
>>
>> EdB
>>
>>
>>
>> On Wed, Apr 24, 2013 at 8:39 PM, Alex Harui <ah...@adobe.com> wrote:
>>> I think I don't have any more commits planned on for flex-asjs unless there
>>> is a bug fix or two. I'm planning to work on a COMPC equivalent for
>>> FalconJX.
>>>
>>> My only criteria for your proposed switch to goog.events are:
>>> 1) is the minified js for the example as small as what we have now?
>>> 2) does it work on IE8?
>>> 3) when writing AS code, do we still get to use dispatchEvent(new Event())?
>>>
>>> If the answer to all 3 is yes, then I don't have a problem moving over to
>>> goog.events. Otherwise, I would say the status quo is the better choice.
>>>
>>>
>>> On 4/24/13 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>>> BTW: the re-write/refactoring was somewhat major, so I plan to publish
>>>> my branch first, so we can review and discuss. It will still be nice
>>>> to have it on par with the 'develop' branch initially, though.
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>>>> Alex,
>>>>>
>>>>> I see you're doing some committing. I have the 'goog.events' based
>>>>> framework done for a previous version of FlexJS and I'm not waiting to
>>>>> update it to the latest and greatest.
>>>>>
>>>>> Do you have any more commits planned for 'today'?
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ix Multimedia Software
>>>>>
>>>>> Jan Luykenstraat 27
>>>>> 3521 VB Utrecht
>>>>>
>>>>> T. 06-51952295
>>>>> I. www.ixsoftware.nl
>>>>
>>>>
>>>
>>> --
>>> 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
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJX][FlexJS] committing?
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Apr 24, 2013 at 9:06 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> There are excellent git GUI applications out there (for the Mac:
> SourceTree, and my personal favorite Tower) that will do all this
> stuff automatically. New branches 'just show up' etc.
>
> IMHO, git is one of those applications that really needs a UI, the
> command line just isn't doing it justice.
>
>
I agree. I know folks should be able to use whatever tool they want
(including command line tools), but a good GUI tool like TortoiseGit or
SmartGit makes a big differences for new comers to Git.
As a bonus, the console window usually shows the commands that get
executed. A great way to learn GIT, IMO.
Thanks,
Om
> EdB
>
>
>
> On Wed, Apr 24, 2013 at 11:15 PM, Dasa Paddock <dp...@esri.com> wrote:
> > It does, but only for the ones that are already known in your repo. It
> doesn't contact the remote to see if there are new ones.
> >
> > Tip: Use git fetch --prune to remove any remote-tracking branches which
> no longer exist on the remote.
> >
> > --Dasa
> >
> > On Apr 24, 2013, at 2:06 PM, Gordon Smith <go...@adobe.com> wrote:
> >
> >> I think 'git branch -r' may list the remote branches even if you don't
> have corresponding local branches.
> >>
> >> - Gordon
> >>
> >> -----Original Message-----
> >> From: Alex Harui [mailto:aharui@adobe.com]
> >> Sent: Wednesday, April 24, 2013 12:53 PM
> >> To: dev@flex.apache.org
> >> Subject: Re: [FalconJX][FlexJS] committing?
> >>
> >> That's something I don't like about Git. I have to pull to see a
> listing of new public branches.
> >>
> >>
> >> On 4/24/13 12:35 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >>
> >>> There is (in my GUI at least) now a remote branch 'goog.events'.
> >>>
> >>> EdB
> >>>
> >>>
> >>>
> >>> On Wed, Apr 24, 2013 at 9:20 PM, Alex Harui <ah...@adobe.com> wrote:
> >>>> Also, I am not seeing a new public branch for these changes. Did you
> >>>> just commit them instead?
> >>>>
> >>>>
> >>>> On 4/24/13 12:08 PM, "Alex Harui" <ah...@adobe.com> wrote:
> >>>>
> >>>>> I'm just starting to look at the diffs. But please, no variables
> >>>>> named "assing" :-)
> >>>>>
> >>>>> So do you really believe it will take more than 6K of minified code
> >>>>> to fix any bugs related to events in the current implementation?
> >>>>>
> >>>>> I'm wondering if the motivation behind goog.events is to get an
> >>>>> event system to work across a lot of older browsers we don't care
> >>>>> about these days like
> >>>>> IE6 and IE7. If that's the case, why take on all of that code?
> >>>>>
> >>>>> I know when Adobe wrote the JS layer for BrowserManager it had a lot
> >>>>> of code paths we can probably drop if we don't have to support older
> browsers.
> >>>>>
> >>>>> I wouldn't want to take a 6K hit unless we really understand what
> >>>>> we're getting for it.
> >>>>>
> >>>>>
> >>>>> On 4/24/13 11:45 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >>>>>
> >>>>>> In short (I have the branch updated and ready to be published: yes
> >>>>>> to all
> >>>>>> three:
> >>>>>>
> >>>>>> 1) it adds about 6k to the file (26k -> 32k)
> >>>>>> 2) yes, without modification, so no more IE8Utils or whatever
> >>>>>> 3) yes
> >>>>>>
> >>>>>> But I'll still publish a branch first, so you can see for yourself
> >>>>>> (there are some other changes/fixes in there as well).
> >>>>>>
> >>>>>> EdB
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Apr 24, 2013 at 8:39 PM, Alex Harui <ah...@adobe.com>
> wrote:
> >>>>>>> I think I don't have any more commits planned on for flex-asjs
> >>>>>>> unless there is a bug fix or two. I'm planning to work on a COMPC
> >>>>>>> equivalent for FalconJX.
> >>>>>>>
> >>>>>>> My only criteria for your proposed switch to goog.events are:
> >>>>>>> 1) is the minified js for the example as small as what we have now?
> >>>>>>> 2) does it work on IE8?
> >>>>>>> 3) when writing AS code, do we still get to use dispatchEvent(new
> >>>>>>> Event())?
> >>>>>>>
> >>>>>>> If the answer to all 3 is yes, then I don't have a problem moving
> >>>>>>> over to goog.events. Otherwise, I would say the status quo is the
> better choice.
> >>>>>>>
> >>>>>>>
> >>>>>>> On 4/24/13 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >>>>>>>
> >>>>>>>> BTW: the re-write/refactoring was somewhat major, so I plan to
> >>>>>>>> publish my branch first, so we can review and discuss. It will
> >>>>>>>> still be nice to have it on par with the 'develop' branch
> initially, though.
> >>>>>>>>
> >>>>>>>> EdB
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin
> >>>>>>>> <er...@ixsoftware.nl>
> >>>>>>>> wrote:
> >>>>>>>>> Alex,
> >>>>>>>>>
> >>>>>>>>> I see you're doing some committing. I have the 'goog.events'
> >>>>>>>>> based framework done for a previous version of FlexJS and I'm
> >>>>>>>>> not waiting to update it to the latest and greatest.
> >>>>>>>>>
> >>>>>>>>> Do you have any more commits planned for 'today'?
> >>>>>>>>>
> >>>>>>>>> EdB
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Ix Multimedia Software
> >>>>>>>>>
> >>>>>>>>> Jan Luykenstraat 27
> >>>>>>>>> 3521 VB Utrecht
> >>>>>>>>>
> >>>>>>>>> T. 06-51952295
> >>>>>>>>> I. www.ixsoftware.nl
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> 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
> >>>>
> >>>
> >>>
> >>
> >> --
> >> Alex Harui
> >> Flex SDK Team
> >> Adobe Systems, Inc.
> >> http://blogs.adobe.com/aharui
> >>
> >>
> >
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: [FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
There are excellent git GUI applications out there (for the Mac:
SourceTree, and my personal favorite Tower) that will do all this
stuff automatically. New branches 'just show up' etc.
IMHO, git is one of those applications that really needs a UI, the
command line just isn't doing it justice.
EdB
On Wed, Apr 24, 2013 at 11:15 PM, Dasa Paddock <dp...@esri.com> wrote:
> It does, but only for the ones that are already known in your repo. It doesn't contact the remote to see if there are new ones.
>
> Tip: Use git fetch --prune to remove any remote-tracking branches which no longer exist on the remote.
>
> --Dasa
>
> On Apr 24, 2013, at 2:06 PM, Gordon Smith <go...@adobe.com> wrote:
>
>> I think 'git branch -r' may list the remote branches even if you don't have corresponding local branches.
>>
>> - Gordon
>>
>> -----Original Message-----
>> From: Alex Harui [mailto:aharui@adobe.com]
>> Sent: Wednesday, April 24, 2013 12:53 PM
>> To: dev@flex.apache.org
>> Subject: Re: [FalconJX][FlexJS] committing?
>>
>> That's something I don't like about Git. I have to pull to see a listing of new public branches.
>>
>>
>> On 4/24/13 12:35 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>> There is (in my GUI at least) now a remote branch 'goog.events'.
>>>
>>> EdB
>>>
>>>
>>>
>>> On Wed, Apr 24, 2013 at 9:20 PM, Alex Harui <ah...@adobe.com> wrote:
>>>> Also, I am not seeing a new public branch for these changes. Did you
>>>> just commit them instead?
>>>>
>>>>
>>>> On 4/24/13 12:08 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>>
>>>>> I'm just starting to look at the diffs. But please, no variables
>>>>> named "assing" :-)
>>>>>
>>>>> So do you really believe it will take more than 6K of minified code
>>>>> to fix any bugs related to events in the current implementation?
>>>>>
>>>>> I'm wondering if the motivation behind goog.events is to get an
>>>>> event system to work across a lot of older browsers we don't care
>>>>> about these days like
>>>>> IE6 and IE7. If that's the case, why take on all of that code?
>>>>>
>>>>> I know when Adobe wrote the JS layer for BrowserManager it had a lot
>>>>> of code paths we can probably drop if we don't have to support older browsers.
>>>>>
>>>>> I wouldn't want to take a 6K hit unless we really understand what
>>>>> we're getting for it.
>>>>>
>>>>>
>>>>> On 4/24/13 11:45 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>>
>>>>>> In short (I have the branch updated and ready to be published: yes
>>>>>> to all
>>>>>> three:
>>>>>>
>>>>>> 1) it adds about 6k to the file (26k -> 32k)
>>>>>> 2) yes, without modification, so no more IE8Utils or whatever
>>>>>> 3) yes
>>>>>>
>>>>>> But I'll still publish a branch first, so you can see for yourself
>>>>>> (there are some other changes/fixes in there as well).
>>>>>>
>>>>>> EdB
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 24, 2013 at 8:39 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>>> I think I don't have any more commits planned on for flex-asjs
>>>>>>> unless there is a bug fix or two. I'm planning to work on a COMPC
>>>>>>> equivalent for FalconJX.
>>>>>>>
>>>>>>> My only criteria for your proposed switch to goog.events are:
>>>>>>> 1) is the minified js for the example as small as what we have now?
>>>>>>> 2) does it work on IE8?
>>>>>>> 3) when writing AS code, do we still get to use dispatchEvent(new
>>>>>>> Event())?
>>>>>>>
>>>>>>> If the answer to all 3 is yes, then I don't have a problem moving
>>>>>>> over to goog.events. Otherwise, I would say the status quo is the better choice.
>>>>>>>
>>>>>>>
>>>>>>> On 4/24/13 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>>>>
>>>>>>>> BTW: the re-write/refactoring was somewhat major, so I plan to
>>>>>>>> publish my branch first, so we can review and discuss. It will
>>>>>>>> still be nice to have it on par with the 'develop' branch initially, though.
>>>>>>>>
>>>>>>>> EdB
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin
>>>>>>>> <er...@ixsoftware.nl>
>>>>>>>> wrote:
>>>>>>>>> Alex,
>>>>>>>>>
>>>>>>>>> I see you're doing some committing. I have the 'goog.events'
>>>>>>>>> based framework done for a previous version of FlexJS and I'm
>>>>>>>>> not waiting to update it to the latest and greatest.
>>>>>>>>>
>>>>>>>>> Do you have any more commits planned for 'today'?
>>>>>>>>>
>>>>>>>>> EdB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ix Multimedia Software
>>>>>>>>>
>>>>>>>>> Jan Luykenstraat 27
>>>>>>>>> 3521 VB Utrecht
>>>>>>>>>
>>>>>>>>> T. 06-51952295
>>>>>>>>> I. www.ixsoftware.nl
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>
>>>
>>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJX][FlexJS] committing?
Posted by Dasa Paddock <dp...@esri.com>.
It does, but only for the ones that are already known in your repo. It doesn't contact the remote to see if there are new ones.
Tip: Use git fetch --prune to remove any remote-tracking branches which no longer exist on the remote.
--Dasa
On Apr 24, 2013, at 2:06 PM, Gordon Smith <go...@adobe.com> wrote:
> I think 'git branch -r' may list the remote branches even if you don't have corresponding local branches.
>
> - Gordon
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Wednesday, April 24, 2013 12:53 PM
> To: dev@flex.apache.org
> Subject: Re: [FalconJX][FlexJS] committing?
>
> That's something I don't like about Git. I have to pull to see a listing of new public branches.
>
>
> On 4/24/13 12:35 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>> There is (in my GUI at least) now a remote branch 'goog.events'.
>>
>> EdB
>>
>>
>>
>> On Wed, Apr 24, 2013 at 9:20 PM, Alex Harui <ah...@adobe.com> wrote:
>>> Also, I am not seeing a new public branch for these changes. Did you
>>> just commit them instead?
>>>
>>>
>>> On 4/24/13 12:08 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>
>>>> I'm just starting to look at the diffs. But please, no variables
>>>> named "assing" :-)
>>>>
>>>> So do you really believe it will take more than 6K of minified code
>>>> to fix any bugs related to events in the current implementation?
>>>>
>>>> I'm wondering if the motivation behind goog.events is to get an
>>>> event system to work across a lot of older browsers we don't care
>>>> about these days like
>>>> IE6 and IE7. If that's the case, why take on all of that code?
>>>>
>>>> I know when Adobe wrote the JS layer for BrowserManager it had a lot
>>>> of code paths we can probably drop if we don't have to support older browsers.
>>>>
>>>> I wouldn't want to take a 6K hit unless we really understand what
>>>> we're getting for it.
>>>>
>>>>
>>>> On 4/24/13 11:45 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>
>>>>> In short (I have the branch updated and ready to be published: yes
>>>>> to all
>>>>> three:
>>>>>
>>>>> 1) it adds about 6k to the file (26k -> 32k)
>>>>> 2) yes, without modification, so no more IE8Utils or whatever
>>>>> 3) yes
>>>>>
>>>>> But I'll still publish a branch first, so you can see for yourself
>>>>> (there are some other changes/fixes in there as well).
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 24, 2013 at 8:39 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>> I think I don't have any more commits planned on for flex-asjs
>>>>>> unless there is a bug fix or two. I'm planning to work on a COMPC
>>>>>> equivalent for FalconJX.
>>>>>>
>>>>>> My only criteria for your proposed switch to goog.events are:
>>>>>> 1) is the minified js for the example as small as what we have now?
>>>>>> 2) does it work on IE8?
>>>>>> 3) when writing AS code, do we still get to use dispatchEvent(new
>>>>>> Event())?
>>>>>>
>>>>>> If the answer to all 3 is yes, then I don't have a problem moving
>>>>>> over to goog.events. Otherwise, I would say the status quo is the better choice.
>>>>>>
>>>>>>
>>>>>> On 4/24/13 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>>>
>>>>>>> BTW: the re-write/refactoring was somewhat major, so I plan to
>>>>>>> publish my branch first, so we can review and discuss. It will
>>>>>>> still be nice to have it on par with the 'develop' branch initially, though.
>>>>>>>
>>>>>>> EdB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin
>>>>>>> <er...@ixsoftware.nl>
>>>>>>> wrote:
>>>>>>>> Alex,
>>>>>>>>
>>>>>>>> I see you're doing some committing. I have the 'goog.events'
>>>>>>>> based framework done for a previous version of FlexJS and I'm
>>>>>>>> not waiting to update it to the latest and greatest.
>>>>>>>>
>>>>>>>> Do you have any more commits planned for 'today'?
>>>>>>>>
>>>>>>>> EdB
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ix Multimedia Software
>>>>>>>>
>>>>>>>> Jan Luykenstraat 27
>>>>>>>> 3521 VB Utrecht
>>>>>>>>
>>>>>>>> T. 06-51952295
>>>>>>>> I. www.ixsoftware.nl
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>
>>
>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
RE: [FalconJX][FlexJS] committing?
Posted by Gordon Smith <go...@adobe.com>.
I think 'git branch -r' may list the remote branches even if you don't have corresponding local branches.
- Gordon
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Wednesday, April 24, 2013 12:53 PM
To: dev@flex.apache.org
Subject: Re: [FalconJX][FlexJS] committing?
That's something I don't like about Git. I have to pull to see a listing of new public branches.
On 4/24/13 12:35 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> There is (in my GUI at least) now a remote branch 'goog.events'.
>
> EdB
>
>
>
> On Wed, Apr 24, 2013 at 9:20 PM, Alex Harui <ah...@adobe.com> wrote:
>> Also, I am not seeing a new public branch for these changes. Did you
>> just commit them instead?
>>
>>
>> On 4/24/13 12:08 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>> I'm just starting to look at the diffs. But please, no variables
>>> named "assing" :-)
>>>
>>> So do you really believe it will take more than 6K of minified code
>>> to fix any bugs related to events in the current implementation?
>>>
>>> I'm wondering if the motivation behind goog.events is to get an
>>> event system to work across a lot of older browsers we don't care
>>> about these days like
>>> IE6 and IE7. If that's the case, why take on all of that code?
>>>
>>> I know when Adobe wrote the JS layer for BrowserManager it had a lot
>>> of code paths we can probably drop if we don't have to support older browsers.
>>>
>>> I wouldn't want to take a 6K hit unless we really understand what
>>> we're getting for it.
>>>
>>>
>>> On 4/24/13 11:45 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>>> In short (I have the branch updated and ready to be published: yes
>>>> to all
>>>> three:
>>>>
>>>> 1) it adds about 6k to the file (26k -> 32k)
>>>> 2) yes, without modification, so no more IE8Utils or whatever
>>>> 3) yes
>>>>
>>>> But I'll still publish a branch first, so you can see for yourself
>>>> (there are some other changes/fixes in there as well).
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Wed, Apr 24, 2013 at 8:39 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>> I think I don't have any more commits planned on for flex-asjs
>>>>> unless there is a bug fix or two. I'm planning to work on a COMPC
>>>>> equivalent for FalconJX.
>>>>>
>>>>> My only criteria for your proposed switch to goog.events are:
>>>>> 1) is the minified js for the example as small as what we have now?
>>>>> 2) does it work on IE8?
>>>>> 3) when writing AS code, do we still get to use dispatchEvent(new
>>>>> Event())?
>>>>>
>>>>> If the answer to all 3 is yes, then I don't have a problem moving
>>>>> over to goog.events. Otherwise, I would say the status quo is the better choice.
>>>>>
>>>>>
>>>>> On 4/24/13 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>>
>>>>>> BTW: the re-write/refactoring was somewhat major, so I plan to
>>>>>> publish my branch first, so we can review and discuss. It will
>>>>>> still be nice to have it on par with the 'develop' branch initially, though.
>>>>>>
>>>>>> EdB
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin
>>>>>> <er...@ixsoftware.nl>
>>>>>> wrote:
>>>>>>> Alex,
>>>>>>>
>>>>>>> I see you're doing some committing. I have the 'goog.events'
>>>>>>> based framework done for a previous version of FlexJS and I'm
>>>>>>> not waiting to update it to the latest and greatest.
>>>>>>>
>>>>>>> Do you have any more commits planned for 'today'?
>>>>>>>
>>>>>>> EdB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ix Multimedia Software
>>>>>>>
>>>>>>> Jan Luykenstraat 27
>>>>>>> 3521 VB Utrecht
>>>>>>>
>>>>>>> T. 06-51952295
>>>>>>> I. www.ixsoftware.nl
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> 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
>>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by Dasa Paddock <dp...@esri.com>.
It's showing up in the "heads" here:
https://git-wip-us.apache.org/repos/asf?p=flex-asjs.git
--Dasa
On Apr 24, 2013, at 12:35 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> There is (in my GUI at least) now a remote branch 'goog.events'.
>
> EdB
>
>
>
> On Wed, Apr 24, 2013 at 9:20 PM, Alex Harui <ah...@adobe.com> wrote:
>> Also, I am not seeing a new public branch for these changes. Did you just
>> commit them instead?
Re: [FalconJX][FlexJS] committing?
Posted by Dasa Paddock <dp...@esri.com>.
A pull is a fetch and a merge, so if you just fetch instead, I don't think "you have to deal with modified files locally".
--Dasa
On Apr 24, 2013, at 1:35 PM, Alex Harui <ah...@adobe.com> wrote:
> Sure, but either way, "git branch -all" doesn't seem to check the repo. The
> list of remotes is stale. You have to fetch or pull which means you have to
> deal with modified files locally.
>
>
> On 4/24/13 1:17 PM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
>
>> Right, Alex try "fetch" command instead of "pull"
>>
>> 2013/4/24 Dasa Paddock <dp...@esri.com>
>>
>>> You can just "fetch" instead:
>>> http://git-scm.com/docs/git-fetch
>>>
>>> --Dasa
>>>
>>> On Apr 24, 2013, at 12:53 PM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>> That's something I don't like about Git. I have to pull to see a listing
>>> of
>>>> new public branches.
>>>
>>>
>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
Sure, but either way, "git branch -all" doesn't seem to check the repo. The
list of remotes is stale. You have to fetch or pull which means you have to
deal with modified files locally.
On 4/24/13 1:17 PM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
> Right, Alex try "fetch" command instead of "pull"
>
> 2013/4/24 Dasa Paddock <dp...@esri.com>
>
>> You can just "fetch" instead:
>> http://git-scm.com/docs/git-fetch
>>
>> --Dasa
>>
>> On Apr 24, 2013, at 12:53 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>> That's something I don't like about Git. I have to pull to see a listing
>> of
>>> new public branches.
>>
>>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Right, Alex try "fetch" command instead of "pull"
2013/4/24 Dasa Paddock <dp...@esri.com>
> You can just "fetch" instead:
> http://git-scm.com/docs/git-fetch
>
> --Dasa
>
> On Apr 24, 2013, at 12:53 PM, Alex Harui <ah...@adobe.com> wrote:
>
> > That's something I don't like about Git. I have to pull to see a listing
> of
> > new public branches.
>
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es
Re: [FalconJX][FlexJS] committing?
Posted by Dasa Paddock <dp...@esri.com>.
You can just "fetch" instead:
http://git-scm.com/docs/git-fetch
--Dasa
On Apr 24, 2013, at 12:53 PM, Alex Harui <ah...@adobe.com> wrote:
> That's something I don't like about Git. I have to pull to see a listing of
> new public branches.
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
That's something I don't like about Git. I have to pull to see a listing of
new public branches.
On 4/24/13 12:35 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> There is (in my GUI at least) now a remote branch 'goog.events'.
>
> EdB
>
>
>
> On Wed, Apr 24, 2013 at 9:20 PM, Alex Harui <ah...@adobe.com> wrote:
>> Also, I am not seeing a new public branch for these changes. Did you just
>> commit them instead?
>>
>>
>> On 4/24/13 12:08 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>> I'm just starting to look at the diffs. But please, no variables named
>>> "assing" :-)
>>>
>>> So do you really believe it will take more than 6K of minified code to fix
>>> any bugs related to events in the current implementation?
>>>
>>> I'm wondering if the motivation behind goog.events is to get an event system
>>> to work across a lot of older browsers we don't care about these days like
>>> IE6 and IE7. If that's the case, why take on all of that code?
>>>
>>> I know when Adobe wrote the JS layer for BrowserManager it had a lot of code
>>> paths we can probably drop if we don't have to support older browsers.
>>>
>>> I wouldn't want to take a 6K hit unless we really understand what we're
>>> getting for it.
>>>
>>>
>>> On 4/24/13 11:45 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>>> In short (I have the branch updated and ready to be published: yes to all
>>>> three:
>>>>
>>>> 1) it adds about 6k to the file (26k -> 32k)
>>>> 2) yes, without modification, so no more IE8Utils or whatever
>>>> 3) yes
>>>>
>>>> But I'll still publish a branch first, so you can see for yourself
>>>> (there are some other changes/fixes in there as well).
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Wed, Apr 24, 2013 at 8:39 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>> I think I don't have any more commits planned on for flex-asjs unless
>>>>> there
>>>>> is a bug fix or two. I'm planning to work on a COMPC equivalent for
>>>>> FalconJX.
>>>>>
>>>>> My only criteria for your proposed switch to goog.events are:
>>>>> 1) is the minified js for the example as small as what we have now?
>>>>> 2) does it work on IE8?
>>>>> 3) when writing AS code, do we still get to use dispatchEvent(new
>>>>> Event())?
>>>>>
>>>>> If the answer to all 3 is yes, then I don't have a problem moving over to
>>>>> goog.events. Otherwise, I would say the status quo is the better choice.
>>>>>
>>>>>
>>>>> On 4/24/13 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>>
>>>>>> BTW: the re-write/refactoring was somewhat major, so I plan to publish
>>>>>> my branch first, so we can review and discuss. It will still be nice
>>>>>> to have it on par with the 'develop' branch initially, though.
>>>>>>
>>>>>> EdB
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin <er...@ixsoftware.nl>
>>>>>> wrote:
>>>>>>> Alex,
>>>>>>>
>>>>>>> I see you're doing some committing. I have the 'goog.events' based
>>>>>>> framework done for a previous version of FlexJS and I'm not waiting to
>>>>>>> update it to the latest and greatest.
>>>>>>>
>>>>>>> Do you have any more commits planned for 'today'?
>>>>>>>
>>>>>>> EdB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ix Multimedia Software
>>>>>>>
>>>>>>> Jan Luykenstraat 27
>>>>>>> 3521 VB Utrecht
>>>>>>>
>>>>>>> T. 06-51952295
>>>>>>> I. www.ixsoftware.nl
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> 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
>>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
There is (in my GUI at least) now a remote branch 'goog.events'.
EdB
On Wed, Apr 24, 2013 at 9:20 PM, Alex Harui <ah...@adobe.com> wrote:
> Also, I am not seeing a new public branch for these changes. Did you just
> commit them instead?
>
>
> On 4/24/13 12:08 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>> I'm just starting to look at the diffs. But please, no variables named
>> "assing" :-)
>>
>> So do you really believe it will take more than 6K of minified code to fix
>> any bugs related to events in the current implementation?
>>
>> I'm wondering if the motivation behind goog.events is to get an event system
>> to work across a lot of older browsers we don't care about these days like
>> IE6 and IE7. If that's the case, why take on all of that code?
>>
>> I know when Adobe wrote the JS layer for BrowserManager it had a lot of code
>> paths we can probably drop if we don't have to support older browsers.
>>
>> I wouldn't want to take a 6K hit unless we really understand what we're
>> getting for it.
>>
>>
>> On 4/24/13 11:45 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>> In short (I have the branch updated and ready to be published: yes to all
>>> three:
>>>
>>> 1) it adds about 6k to the file (26k -> 32k)
>>> 2) yes, without modification, so no more IE8Utils or whatever
>>> 3) yes
>>>
>>> But I'll still publish a branch first, so you can see for yourself
>>> (there are some other changes/fixes in there as well).
>>>
>>> EdB
>>>
>>>
>>>
>>> On Wed, Apr 24, 2013 at 8:39 PM, Alex Harui <ah...@adobe.com> wrote:
>>>> I think I don't have any more commits planned on for flex-asjs unless there
>>>> is a bug fix or two. I'm planning to work on a COMPC equivalent for
>>>> FalconJX.
>>>>
>>>> My only criteria for your proposed switch to goog.events are:
>>>> 1) is the minified js for the example as small as what we have now?
>>>> 2) does it work on IE8?
>>>> 3) when writing AS code, do we still get to use dispatchEvent(new Event())?
>>>>
>>>> If the answer to all 3 is yes, then I don't have a problem moving over to
>>>> goog.events. Otherwise, I would say the status quo is the better choice.
>>>>
>>>>
>>>> On 4/24/13 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>
>>>>> BTW: the re-write/refactoring was somewhat major, so I plan to publish
>>>>> my branch first, so we can review and discuss. It will still be nice
>>>>> to have it on par with the 'develop' branch initially, though.
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>>>>> Alex,
>>>>>>
>>>>>> I see you're doing some committing. I have the 'goog.events' based
>>>>>> framework done for a previous version of FlexJS and I'm not waiting to
>>>>>> update it to the latest and greatest.
>>>>>>
>>>>>> Do you have any more commits planned for 'today'?
>>>>>>
>>>>>> EdB
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ix Multimedia Software
>>>>>>
>>>>>> Jan Luykenstraat 27
>>>>>> 3521 VB Utrecht
>>>>>>
>>>>>> T. 06-51952295
>>>>>> I. www.ixsoftware.nl
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
Also, I am not seeing a new public branch for these changes. Did you just
commit them instead?
On 4/24/13 12:08 PM, "Alex Harui" <ah...@adobe.com> wrote:
> I'm just starting to look at the diffs. But please, no variables named
> "assing" :-)
>
> So do you really believe it will take more than 6K of minified code to fix
> any bugs related to events in the current implementation?
>
> I'm wondering if the motivation behind goog.events is to get an event system
> to work across a lot of older browsers we don't care about these days like
> IE6 and IE7. If that's the case, why take on all of that code?
>
> I know when Adobe wrote the JS layer for BrowserManager it had a lot of code
> paths we can probably drop if we don't have to support older browsers.
>
> I wouldn't want to take a 6K hit unless we really understand what we're
> getting for it.
>
>
> On 4/24/13 11:45 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>> In short (I have the branch updated and ready to be published: yes to all
>> three:
>>
>> 1) it adds about 6k to the file (26k -> 32k)
>> 2) yes, without modification, so no more IE8Utils or whatever
>> 3) yes
>>
>> But I'll still publish a branch first, so you can see for yourself
>> (there are some other changes/fixes in there as well).
>>
>> EdB
>>
>>
>>
>> On Wed, Apr 24, 2013 at 8:39 PM, Alex Harui <ah...@adobe.com> wrote:
>>> I think I don't have any more commits planned on for flex-asjs unless there
>>> is a bug fix or two. I'm planning to work on a COMPC equivalent for
>>> FalconJX.
>>>
>>> My only criteria for your proposed switch to goog.events are:
>>> 1) is the minified js for the example as small as what we have now?
>>> 2) does it work on IE8?
>>> 3) when writing AS code, do we still get to use dispatchEvent(new Event())?
>>>
>>> If the answer to all 3 is yes, then I don't have a problem moving over to
>>> goog.events. Otherwise, I would say the status quo is the better choice.
>>>
>>>
>>> On 4/24/13 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>>> BTW: the re-write/refactoring was somewhat major, so I plan to publish
>>>> my branch first, so we can review and discuss. It will still be nice
>>>> to have it on par with the 'develop' branch initially, though.
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>>>> Alex,
>>>>>
>>>>> I see you're doing some committing. I have the 'goog.events' based
>>>>> framework done for a previous version of FlexJS and I'm not waiting to
>>>>> update it to the latest and greatest.
>>>>>
>>>>> Do you have any more commits planned for 'today'?
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ix Multimedia Software
>>>>>
>>>>> Jan Luykenstraat 27
>>>>> 3521 VB Utrecht
>>>>>
>>>>> T. 06-51952295
>>>>> I. www.ixsoftware.nl
>>>>
>>>>
>>>
>>> --
>>> 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
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
I'm just starting to look at the diffs. But please, no variables named
"assing" :-)
So do you really believe it will take more than 6K of minified code to fix
any bugs related to events in the current implementation?
I'm wondering if the motivation behind goog.events is to get an event system
to work across a lot of older browsers we don't care about these days like
IE6 and IE7. If that's the case, why take on all of that code?
I know when Adobe wrote the JS layer for BrowserManager it had a lot of code
paths we can probably drop if we don't have to support older browsers.
I wouldn't want to take a 6K hit unless we really understand what we're
getting for it.
On 4/24/13 11:45 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> In short (I have the branch updated and ready to be published: yes to all
> three:
>
> 1) it adds about 6k to the file (26k -> 32k)
> 2) yes, without modification, so no more IE8Utils or whatever
> 3) yes
>
> But I'll still publish a branch first, so you can see for yourself
> (there are some other changes/fixes in there as well).
>
> EdB
>
>
>
> On Wed, Apr 24, 2013 at 8:39 PM, Alex Harui <ah...@adobe.com> wrote:
>> I think I don't have any more commits planned on for flex-asjs unless there
>> is a bug fix or two. I'm planning to work on a COMPC equivalent for
>> FalconJX.
>>
>> My only criteria for your proposed switch to goog.events are:
>> 1) is the minified js for the example as small as what we have now?
>> 2) does it work on IE8?
>> 3) when writing AS code, do we still get to use dispatchEvent(new Event())?
>>
>> If the answer to all 3 is yes, then I don't have a problem moving over to
>> goog.events. Otherwise, I would say the status quo is the better choice.
>>
>>
>> On 4/24/13 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>> BTW: the re-write/refactoring was somewhat major, so I plan to publish
>>> my branch first, so we can review and discuss. It will still be nice
>>> to have it on par with the 'develop' branch initially, though.
>>>
>>> EdB
>>>
>>>
>>>
>>> On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>>> Alex,
>>>>
>>>> I see you're doing some committing. I have the 'goog.events' based
>>>> framework done for a previous version of FlexJS and I'm not waiting to
>>>> update it to the latest and greatest.
>>>>
>>>> Do you have any more commits planned for 'today'?
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> --
>>>> Ix Multimedia Software
>>>>
>>>> Jan Luykenstraat 27
>>>> 3521 VB Utrecht
>>>>
>>>> T. 06-51952295
>>>> I. www.ixsoftware.nl
>>>
>>>
>>
>> --
>> 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
Re: [FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
In short (I have the branch updated and ready to be published: yes to all three:
1) it adds about 6k to the file (26k -> 32k)
2) yes, without modification, so no more IE8Utils or whatever
3) yes
But I'll still publish a branch first, so you can see for yourself
(there are some other changes/fixes in there as well).
EdB
On Wed, Apr 24, 2013 at 8:39 PM, Alex Harui <ah...@adobe.com> wrote:
> I think I don't have any more commits planned on for flex-asjs unless there
> is a bug fix or two. I'm planning to work on a COMPC equivalent for
> FalconJX.
>
> My only criteria for your proposed switch to goog.events are:
> 1) is the minified js for the example as small as what we have now?
> 2) does it work on IE8?
> 3) when writing AS code, do we still get to use dispatchEvent(new Event())?
>
> If the answer to all 3 is yes, then I don't have a problem moving over to
> goog.events. Otherwise, I would say the status quo is the better choice.
>
>
> On 4/24/13 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>> BTW: the re-write/refactoring was somewhat major, so I plan to publish
>> my branch first, so we can review and discuss. It will still be nice
>> to have it on par with the 'develop' branch initially, though.
>>
>> EdB
>>
>>
>>
>> On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>> Alex,
>>>
>>> I see you're doing some committing. I have the 'goog.events' based
>>> framework done for a previous version of FlexJS and I'm not waiting to
>>> update it to the latest and greatest.
>>>
>>> Do you have any more commits planned for 'today'?
>>>
>>> EdB
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>
>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJX][FlexJS] committing?
Posted by Alex Harui <ah...@adobe.com>.
I think I don't have any more commits planned on for flex-asjs unless there
is a bug fix or two. I'm planning to work on a COMPC equivalent for
FalconJX.
My only criteria for your proposed switch to goog.events are:
1) is the minified js for the example as small as what we have now?
2) does it work on IE8?
3) when writing AS code, do we still get to use dispatchEvent(new Event())?
If the answer to all 3 is yes, then I don't have a problem moving over to
goog.events. Otherwise, I would say the status quo is the better choice.
On 4/24/13 11:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> BTW: the re-write/refactoring was somewhat major, so I plan to publish
> my branch first, so we can review and discuss. It will still be nice
> to have it on par with the 'develop' branch initially, though.
>
> EdB
>
>
>
> On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>> Alex,
>>
>> I see you're doing some committing. I have the 'goog.events' based
>> framework done for a previous version of FlexJS and I'm not waiting to
>> update it to the latest and greatest.
>>
>> Do you have any more commits planned for 'today'?
>>
>> EdB
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX][FlexJS] committing?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
BTW: the re-write/refactoring was somewhat major, so I plan to publish
my branch first, so we can review and discuss. It will still be nice
to have it on par with the 'develop' branch initially, though.
EdB
On Wed, Apr 24, 2013 at 8:10 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Alex,
>
> I see you're doing some committing. I have the 'goog.events' based
> framework done for a previous version of FlexJS and I'm not waiting to
> update it to the latest and greatest.
>
> Do you have any more commits planned for 'today'?
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl