You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Carlos Rovira <ca...@apache.org> on 2014/03/05 18:19:42 UTC
TextInput JS events
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
Re: TextInput JS events
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I'll try to have a look at this tomorrow.
EdB
On Wed, Mar 5, 2014 at 6:19 PM, Carlos Rovira <ca...@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
Re: TextInput JS events
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Erik,
finally refactored and committed the todo list sample to package
"sample.todo" and change the rest to plural ("controllers", "events", and
so on... in this regard I think we have a compiler bug since if I left
singular, the compiler throw warnings that signals "incomplete alias" (over
17 warnings). Then after going plural, all compiles ok.
I tried a bit your stuff and applied the removal of input handler, but it
seems we have not solved the problem yet. I must to exit now, I'll try it
later. If you can test it and see if with the new package you can see where
could be the problem located let me know, if not I'll come to it later.
btw, maybe this kind of test could be in the basic sample since this
derived while implementing the sample app since it's a very basic need of a
TextInput component, but really I don't need a "change" event there (it
will be an ENTER change to log a todo event).
Thanks
Carlos
2014-03-06 14:31 GMT+01:00 Erik de Bruin <er...@ixsoftware.nl>:
> 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.rovira@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 <er...@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 <er...@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.rovira@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 <er...@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 <
> > > carlosrovira@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
>
--
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: TextInput JS events
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Alex,
I think this is right since as I see it, generated code for JS takes the
role of somewhat like compiled code, regarding there's no developer use and
it's final. So whatever we do to get more speed the better, id we could get
speed with tricks like that we should change from dot notation to
underscore notation.
This weakend I'm on trip and will not be able to see this event stuff, but
I'll get back early next week to see more about this strange issue.
2014-03-06 17:17 GMT+01:00 Alex Harui <ah...@adobe.com>:
> 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" <er...@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.rovira@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 <er...@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 <er...@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.rovira@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 <er...@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 <
> >> > carlosrovira@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
>
>
--
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: TextInput JS events
Posted by Alex Harui <ah...@adobe.com>.
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" <er...@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 <ah...@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" <er...@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.rovira@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 <er...@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 <er...@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.rovira@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 <er...@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 <
>> >> > carlosrovira@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
Re: TextInput JS events
Posted by Erik de Bruin <er...@ixsoftware.nl>.
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 <ah...@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" <er...@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.rovira@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 <er...@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 <er...@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.rovira@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 <er...@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 <
> >> > carlosrovira@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
Re: TextInput JS events
Posted by Alex Harui <ah...@adobe.com>.
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" <er...@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.rovira@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 <er...@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 <er...@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.rovira@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 <er...@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 <
>> > carlosrovira@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
Re: TextInput JS events
Posted by Erik de Bruin <er...@ixsoftware.nl>.
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.rovira@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 <er...@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 <er...@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.rovira@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 <er...@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 <
> > carlosrovira@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
Re: TextInput JS events
Posted by Carlos Rovira <ca...@codeoscopic.com>.
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 <er...@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 <er...@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.rovira@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 <er...@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 <
> carlosrovira@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
Re: TextInput JS events
Posted by Erik de Bruin <er...@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 <er...@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.rovira@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 <er...@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 <carlosrovira@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
Re: TextInput JS events
Posted by Erik de Bruin <er...@ixsoftware.nl>.
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.rovira@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 <er...@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 <carlosrovira@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
Re: TextInput JS events
Posted by Carlos Rovira <ca...@codeoscopic.com>.
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 <er...@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 <carlosrovira@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
Re: TextInput JS events
Posted by Erik de Bruin <er...@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 <ca...@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
Re: TextInput JS events
Posted by Alex Harui <ah...@adobe.com>.
Hi Carlos,
We don't have a strict policy on that yet. We could just call event
"input" and kill the textInput event on the SWF side and dispatch it as
"input". That would have backward compatibility problems for Flex users
expecting "textInput", but FlexJS doesn't promise 100% compatibility.
I thought Google Closure supported a stopImmediatePropagation API so you
could kill "input" on the JS side and dispatch "textInput" instead.
In most cases for FlexJS, we want to encapsulate browser behavior and
emulate it in AS/SWF so the fin al JS/HTML/CSS app runs as efficiently as
possible, but sometimes we'll add some code to JS to emulate old Flex
behavior if we think it is going to improve usability/portability. In
this case, it would depend on how much code it takes to emulate
TextField's events in JS.
Thanks,
-Alex
On 3/5/14 9:19 AM, "Carlos Rovira" <ca...@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