Well, either way, thanks for bringing it to my
attention. I dig the low level things, and this is pretty cool to know
that it's that common across all UIComponents, in both 1.5 and 2.
The TextInput thing I mentioned, I didn't
build. I was using TextInputs everywhere, and my team members were like,
"Dude, what are you doing?". They said to use one they built. It had
basically 3 things; a specific look the client liked, made 2 events into 1, and
maxChar as a public property. There were 2 other minor things. I
think the reason it was built was because the most common use case was needing
both enter & focusOut to fire update events, and since they were using this
in forms everywhere, they reduced a ton of code by refactoring it this
way.
In Flex 1.5, yes, this has a cost.
Inheritance in Flash Player 8 and below has a cost, mainly because of the
inheritance chain and method lookups. If a method is invoked, and it's not
on "you", it asks its parent class. This chain lookup is expensive.
So gregarious extending does cause performance impacts.
This problem doesn't exist in Flex 2 because of the
new traits object (vs. prototype). So, now, it's more of a decision of
"should we use inteheritance" with no need to worry about performance
impacts.
As far as consolidition, I think the above example
is extremely helpful. We have a common use case for the control, and it
has a specific design, so yeah man, extending it for that simple reason has
helped a lot. It's easier to handle the look in Flex 2 because CSS is soo
much cooler now.
Well, yeah, the change thing is an issue.
However, I'm usually the one digging around in base classes. I have to the
balls to know if I do one thing wrong, I've broken like 200 uses of the
control... so it better not be wrong! Seriously, though, we do some
refactoring, but I think my boss & the rest of the team's early decisions
were good ones with forethought, so I havent' run into that problem too
much.
Naw, thanks again for letting me know, I
had no clue that property existed.
----- Original Message -----
Sent: Wednesday, July 12, 2006 3:02 AM
Subject: RE: [flexcoders] viewstack design pattern issue
I didn't hear about it,
I just kind of came across it while working on a runtime xml double binding
solution for a future product. I tried various events but not worked as well as
that one. I only used 1.5 for about 2 months while I was learning flex so
can't comment on that one. Agreed that when you need immediate updates it would
not work, I guess everything has it's limitations.
Do you think (any sorry
for being off topic) that when you have the same events being used in multiple
controls of the same, type that it is better to refactor that into a separate
extended control? For example buttons on a menu. If they all use the same style,
height, language tags for tool tip, and text, and all call the same command
controller. Ive been pondering this for a while, and though it is easier to
code, and cleaner to look at I thought it would bloat the final product (I try
not to go to far with regards to this stuff). What are your experiences on this?
Im thinking for
maintenance it has to be better, but if a little change is required on a
component that uses it, you cant change that extended one, and would be
required to create another extended component, resulting in multiple extended
components all almost the same. I hope the question makes
sense.
So to extend or not to
extend? :)
back to
topic:
I wasnt questioning
your method here, just qualifying the way I do it, and found
myself questioning the methods Id chosen after reading your
post.
Jason
-----Message
d'origine----- De :
flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED]De la part
de JesterXL Envoyé : mercredi 12 juillet 2006
02:02 À : flexcoders@yahoogroups.com Objet : Re:
[flexcoders] viewstack design pattern issue
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]ups.com> 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]ups.com
[mailto:[EMAIL PROTECTED]ups.com]De
la part de JesterXL Envoyé : mardi 11 juillet 2006 18:25 À : [EMAIL PROTECTED]ups.com 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]ups.com 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]ups.com
[mailto:[EMAIL PROTECTED]ups.com]De
la part de JesterXL Envoyé : mardi 11 juillet 2006 15:46 À : [EMAIL PROTECTED]ups.com 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]ups.com 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
__._,_.___
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
__,_._,___
|