But would flattening our namespaces get around package name collisions
that Carlos ran into? Doing so wouldn't negatively affect Closure's
output, or would it?
-Alex
On 3/8/14 8:54 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>The Closure compiler flattens namespaces (dot notation) for us, among many
>other optimisations. There is really no need to be worry about stuff like
>that.
>
>The GCC is really an awesome tool, you should check out it's output
>sometime, you'll be amazed how much optimisation it achieves if fed a
>properly structured and annotated source!
>
>Thanks,
>
>EdB
>
>
>
>
>On Thu, Mar 6, 2014 at 5:17 PM, Alex Harui <aha...@adobe.com> wrote:
>
>> FWIW, what subsystems or anything requires us to use dot.path
>>expressions
>> for packages? The original FalconJS developer mentioned to me once that
>> we should consider having FalconJX flatten the packages
>> (org_apache_flex_TextInput instead of org.apache.flex.TextInput) because
>> it looks up faster in JS. And I think that would prevent this problem
>>as
>> well?
>>
>> Thoughts?
>>
>> -Alex
>>
>> On 3/6/14 5:31 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>>
>> >If you are going to use 'org.apache.flex' for you app you run the risk
>>of
>> >collisions with the SDK, which also uses that namespace.
>> >
>> >Also, the plural ("events") makes more sense - to me at least - as
>>there
>> >will likely be more classes in that one package: events.firstEvent,
>> >events.secondEvent, events.someOtherEvent... But that is entirely up to
>> >the
>> >application developer, of course.
>> >
>> >EdB
>> >
>> >
>> >
>> >
>> >On Thu, Mar 6, 2014 at 2:27 PM, Carlos Rovira
>> ><carlos.rov...@codeoscopic.com
>> >> wrote:
>> >
>> >> Hi Erik,
>> >>
>> >> I see the point and I was thinking to introduce "org.apache.flex" to
>> >>solve
>> >> a similar problem I send to this list some days ago thinking that it
>> >>was a
>> >> bug in the compiler, but the problem is the package structure. I
>>prefer
>> >> introduce "org.apache.flex" and then maintain packages in singular
>> >>since I
>> >> think it's a better namespace convention than plural.
>> >> I'll make the change later as I get some time for FlexJS.
>> >>
>> >> Thanks!
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> 2014-03-06 13:41 GMT+01:00 Erik de Bruin <e...@ixsoftware.nl>:
>> >>
>> >> > As a first try, I'd suggest you rename the "event" package to
>> >>something
>> >> > less collision prone, like "events"...
>> >> >
>> >> > EdB
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Mar 6, 2014 at 1:29 PM, Erik de Bruin <e...@ixsoftware.nl>
>> >> wrote:
>> >> >
>> >> > > Carlos,
>> >> > >
>> >> > > I'm currently looking at the example application. You use
>>'event' as
>> >> part
>> >> > > of the namespace. In FlexJS JS, all objects are fully qualified,
>>so
>> >> where
>> >> > > in AS you would have "new TodoListEvent(TodoListEvent.LOG_TODO)",
>> >>in JS
>> >> > > that will become "new
>> >> event.TodoListEvent(event.TodoListEvent.LOG_TODO)".
>> >> > > Now this becomes a problem, as "event" is not only in your
>> >>namespace,
>> >> you
>> >> > > use it as a function parameter name and (at least in IE) it is a
>> >>global
>> >> > > variable. So, some of the problems you have with the app probably
>> >>come
>> >> > from
>> >> > > the browser not knowing which "event" object reference to
>>resolve a
>> >> > > variable to, choosing the wrong one: voila! exception :-(
>> >> > >
>> >> > > I'll continue looking to see if I can find a fix that is not too
>> >> intense.
>> >> > >
>> >> > > EdB
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > On Thu, Mar 6, 2014 at 12:35 PM, Carlos Rovira <
>> >> > > carlos.rov...@codeoscopic.com> wrote:
>> >> > >
>> >> > >> Hi Erik,
>> >> > >>
>> >> > >> thanks, I have a version locally without the need of
>>InputHandler
>> >>goog
>> >> > >> class to remove that dependency, but although I'm with you that
>> >>this
>> >> > >> solution should be the right from a design perspective it's not
>> >> working
>> >> > >> for
>> >> > >> me. The method is getting called due to MXMLDataInterpreter
>>setup
>> >> > >> internals
>> >> > >> (so it seems to be out of the control and scope of developer)
>>and
>> >>not
>> >> > due
>> >> > >> to the CHANGE event that TextInput.js propagates (if I remove
>>this
>> >> > >> listener/event the change *native* event is operating and is
>>what I
>> >> > think
>> >> > >> we should remove in some way, maybe patching the
>> >>MXMLDataInterpreter
>> >> to
>> >> > >> avoid making a listener of text input to change event).
>> >> > >>
>> >> > >> Maybe with your changes now you get it working (could you
>>confirm)?
>> >> that
>> >> > >> would be great since after thinking in my proposal and Alex
>> >>comments I
>> >> > >> would prefer to maintain Flex API as possible and not going to
>>map
>> >>JS
>> >> > >> 'input' event. FlexJS users would expect CHANGE to work as they
>>do
>> >>in
>> >> > >> traditional Flex.
>> >> > >>
>> >> > >> I'm this morning out, but I'd like to get it back to this issue
>> >>this
>> >> > >> night.
>> >> > >>
>> >> > >> Thanks Erik for take the time to see this since you're more
>> >> experienced
>> >> > >> with all this JS stuff and it's good to have your validation.
>> >> > >>
>> >> > >> Best,
>> >> > >>
>> >> > >> Carlos
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> 2014-03-06 9:29 GMT+01:00 Erik de Bruin <e...@ixsoftware.nl>:
>> >> > >>
>> >> > >> > Carlos,
>> >> > >> >
>> >> > >> > In your JS implementation I see you already set up a handler
>>that
>> >> > >> catches
>> >> > >> > "input" events and re-casts them as "change" events. This
>>seems
>> >> like a
>> >> > >> > perfectly acceptable solution to this issue and much more
>>clean
>> >>and
>> >> > >> > intuitive than trying to get the AS side to emit "input"
>>instead
>> >>of
>> >> > >> change,
>> >> > >> > and have your users work with that 'unfamiliar' event.
>> >> > >> >
>> >> > >> > I've changed the visibility of the 'inputChangeHandler' to
>> >>private,
>> >> as
>> >> > >> this
>> >> > >> > method shouldn't be overridden, and added a call to
>> >> 'stopPropagation'
>> >> > >> for
>> >> > >> > the original event (as Alex suggested), so it doesn't
>>interfere
>> >>or
>> >> > >> confuse
>> >> > >> > things later in the chain.
>> >> > >> >
>> >> > >> > Nice work!
>> >> > >> >
>> >> > >> > EdB
>> >> > >> >
>> >> > >> >
>> >> > >> >
>> >> > >> >
>> >> > >> > On Wed, Mar 5, 2014 at 6:19 PM, Carlos Rovira <
>> >> > carlosrov...@apache.org
>> >> > >> > >wrote:
>> >> > >> >
>> >> > >> > > Hi,
>> >> > >> > >
>> >> > >> > > I'm trying to deal with events in JS and I'm finding some
>> >> troubles.
>> >> > >> Maybe
>> >> > >> > > you guys more experienced with google closure could help me
>>to
>> >> find
>> >> > >> the
>> >> > >> > > way.
>> >> > >> > >
>> >> > >> > > In old Flex SDK, TextInput change event is used to signal
>> >>changes
>> >> in
>> >> > >> text
>> >> > >> > > as user introduces. In JS input text that event is 'input',
>> >>while
>> >> > >> > 'change'
>> >> > >> > > is called when the text is different and the user press
>>ENTER
>> >>key
>> >> or
>> >> > >> > > changes focus.
>> >> > >> > >
>> >> > >> > > If we make the following declaration in a MXML View:
>> >> > >> > >
>> >> > >> > > <basic:TextInput id="myTextInput"
>> >> > >> > > width="300"
>> >> > >> > > change="doSomething()"/>
>> >> > >> > >
>> >> > >> > > This generate the following JS code in get_MXMLDescriptor:
>> >> > >> > >
>> >> > >> > > ...
>> >> > >> > > [org.apache.flex.html.staticControls.TextInput, 2, 'id',
>>true,
>> >> > >> > > 'myTextInput', 'width', true, 300, 0, 1, 'change',
>>this.$EH0,
>> >> null,
>> >> > >> > > ...
>> >> > >> > >
>> >> > >> > > This makes the TextInput work as expected in SWF
>>(doSomething
>> >>runs
>> >> > on
>> >> > >> > each
>> >> > >> > > character introduced on TextInput)
>> >> > >> > >
>> >> > >> > > But In JS, without implement anything yet in TextInput.js
>>about
>> >> > input
>> >> > >> > text
>> >> > >> > > handling events, the generated code makes doSomething method
>> >>runs
>> >> > when
>> >> > >> > user
>> >> > >> > > press ENTER or focus out if text was changed. I tried to
>> >>implement
>> >> > >> CHANGE
>> >> > >> > > event with no luck due to the listener generated behind the
>> >>scenes
>> >> > >> that
>> >> > >> > > match the same name as native textinput change event.
>> >> > >> > >
>> >> > >> > > Note that If I rename 'change' to 'input' in all places,
>> >>including
>> >> > >> > > TextInput.as metadata event declaration it works ok, since
>> >>event
>> >> > match
>> >> > >> > the
>> >> > >> > > input js event. It looks like this:
>> >> > >> > >
>> >> > >> > > <basic:TextInput id="myTextInput"
>> >> > >> > > width="300"
>> >> > >> > > input="doSomething()"/>
>> >> > >> > >
>> >> > >> > > What could we do here? Should we patch MXMLDataInterpreter
>> >>class
>> >> to
>> >> > >> deal
>> >> > >> > > with this particularities (maybe translate 'change' to
>>'input'
>> >> > behind
>> >> > >> the
>> >> > >> > > scenes to maintain 'change in AS side)? change from
>>traditional
>> >> Flex
>> >> > >> > events
>> >> > >> > > to something more JS (so using 'input' instead of 'change'?
>> >> > >> > >
>> >> > >> > > If you find this kind of problems before, maybe you already
>>has
>> >> some
>> >> > >> > > strategy or framework design rule to follow.
>> >> > >> > >
>> >> > >> > > Thanks
>> >> > >> > >
>> >> > >> > > Carlos
>> >> > >> > >
>> >> > >> > >
>> >> > >> > > --
>> >> > >> > > Carlos Rovira
>> >> > >> > > http://about.me/carlosrovira
>> >> > >> > >
>> >> > >> >
>> >> > >> >
>> >> > >> >
>> >> > >> > --
>> >> > >> > Ix Multimedia Software
>> >> > >> >
>> >> > >> > Jan Luykenstraat 27
>> >> > >> > 3521 VB Utrecht
>> >> > >> >
>> >> > >> > T. 06-51952295
>> >> > >> > I. www.ixsoftware.nl
>> >> > >> >
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> --
>> >> > >> 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
>> >> > >>
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > 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
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> 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
>> >>
>> >
>> >
>> >
>> >--
>> >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
