3 things.
First, valueCommitted in Flex 1.5 does not always fire at the appropriate
times. For example, it doesn't fire when you chang text in a TextInput
field. Also, it doesn't fire when you hit the enter key. Sometimes, these
are desirable events to set data. It only works for focusOut.
So, using the default components in Flex 1.5, I have to do:
<mx:TextInput id="my_ti" enter="doCommit()" focusOut="doCommit()" />
function doCommit()
{
myVal = my_ti.text;
}
vs. using an extended component that makes both events into 1:
<view:ATextInput id="my_ti" valueComit="doCommit()" />
See?
Second, in Flex 2, it doesn't fire until the focus goes to another control.
Finally, neither work with change. Change is a valid event because
sometimes you need immediate updates. ValueCommitted / ValueCommit is a
boilerplate event. I wasn't aware of it in either versions of Flex until
you mentioned it. It seems as long as you don't need specific events, it is
a good catch all to use. :: shrugs :: Where did you hear about?
----- Original Message -----
From: "Jason Hawryluk" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, July 11, 2006 6:03 PM
Subject: RE: [flexcoders] viewstack design pattern issue
I don't quite understand how that could be less code?
>From the doc's
"The valueCommit event is triggered when a user completes data entry into a
control or the value of the control is changed programmatically"
It has nothing to do with the change event.
>From what I gather valueCommit was designed for just that purpose. The
focusout + enter solution only works for some scenarios.
As every control has a valueCommit, and it's suggested to use valueCommit
when validating the data entered.
jason
-----Message d'origine-----
De : [email protected] [mailto:[EMAIL PROTECTED] la
part de JesterXL
Envoyé : mardi 11 juillet 2006 18:25
À : [email protected]
Objet : Re: [flexcoders] viewstack design pattern issue
:: shrugs :: Never used valueCommitted. Using change for a TextInput for
example causes problems because sometimes updating every key stroke causes
updates to happen too fast. focusOut ensures it only happens when the user
is "done" with the TextInput. You can use enter, as well.
We have a component in our apps that extends TextInput, and conslidates both
enter & focusOut into a "valueComitted" event as it were. Less coding
anyway.
----- Original Message -----
From: Jason Hawryluk
To: [email protected]
Sent: Tuesday, July 11, 2006 11:47 AM
Subject: RE: [flexcoders] viewstack design pattern issue
JesterXL ? Focusout changes data on the textinput ? What if the user just
get focus into the textinput, and does not change it?
I'm using valueCommit on all components. Is focus out better for this ?
Hank: Are you opening the same data multiple times, and you require that
related screens are observed ? I.e. update one, the other updates kind of
thing?
Jason
-----Message d'origine-----
De : [email protected] [mailto:[EMAIL PROTECTED] la
part de JesterXL
Envoyé : mardi 11 juillet 2006 15:46
À : [email protected]
Objet : Re: [flexcoders] viewstack design pattern issue
We use a dirty flag. We set it to true whenever some data changes. This
data change is detected by registering for control events that change data
(focusOut for TextInput, selectedDate != null for DateChooser, etc.). These
events change the data if applicable, and set the dirty flag.
Other components can bind to the dirty flag and take appropriate actions,
whether via a getter / setter or the binding tag.
----- Original Message -----
From: hank williams
To: [email protected]
Sent: Tuesday, July 11, 2006 9:20 AM
Subject: [flexcoders] viewstack design pattern issue
I have a viewstack (actually a tabnavigator) that has screens with data that
comes from a server.
I want to trigger the screen to go out and get new data only when:
1. the user enters the specific viewstack sub screen, and
2. when the data for that screen is dirty, based on some bound data that
has triggered a change
So as I see it, the screen needs to keep track of when the bound field has
changed which should cause a call to get fresh data. This means that the
screen must keep track of whether it is dirty.
This seems like it must be a common scenario, and I am curious about how
other people handle it. My first instinct was to create a base screen class
from which all my screens could inherit. But I am curious whether cairngorm
already handles this or whether this is even part of the scope of what it
tries to cover. I am not using cairngorm right now, but may in the future.
But understanding what is and isnt in its scope is important for me to start
to understand.
So anyway, this is a 2 part question.
1. how do people handle this situation
2. does cairngorm have some pre-packaged solution to this issue.
Hank
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
Yahoo! Groups Links
------------------------ Yahoo! Groups Sponsor --------------------~-->
Yahoo! Groups gets a make over. See the new email design.
http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
