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" <carlosrov...@apache.org> wrote:

>Hi,
>
>I'm trying to deal with events in JS and I'm finding some troubles. Maybe
>you guys more experienced with google closure could help me to find the
>way.
>
>In old Flex SDK, TextInput change event is used to signal changes in text
>as user introduces. In JS input text that event is 'input', while 'change'
>is called when the text is different and the user press ENTER key or
>changes focus.
>
>If we make the following declaration in a MXML View:
>
><basic:TextInput id="myTextInput"
>                         width="300"
>                         change="doSomething()"/>
>
>This generate the following JS code in get_MXMLDescriptor:
>
>...
>[org.apache.flex.html.staticControls.TextInput, 2, 'id', true,
>'myTextInput', 'width', true, 300, 0, 1, 'change', this.$EH0, null,
>...
>
>This makes the TextInput work as expected in SWF (doSomething runs on each
>character introduced on TextInput)
>
>But In JS, without implement anything yet in TextInput.js about input text
>handling events, the generated code makes doSomething method runs when
>user
>press ENTER or focus out if text was changed. I tried to implement CHANGE
>event with no luck due to the listener generated behind the scenes that
>match the same name as native textinput change event.
>
>Note that If I rename 'change' to 'input' in all places, including
>TextInput.as metadata event declaration it works ok, since event match the
>input js event. It looks like this:
>
><basic:TextInput id="myTextInput"
>                         width="300"
>                         input="doSomething()"/>
>
>What could we do here? Should we patch MXMLDataInterpreter class to deal
>with this particularities (maybe translate 'change' to 'input' behind the
>scenes to maintain 'change in AS side)? change from traditional Flex
>events
>to something more JS (so using 'input' instead of 'change'?
>
>If you find this kind of problems before, maybe you already has some
>strategy or framework design rule to follow.
>
>Thanks
>
>Carlos
>
>
>-- 
>Carlos Rovira
>http://about.me/carlosrovira

Reply via email to