Hi,
I'm a cairngorm newbie, and still not sure of what solution is
appropriate for a certain situation but in case I want to update the
view after a command has taken an action I would follow one of the
following:
1. A direct data binding that is the most elegant I think but doesn't
always fit. I've seen some cairngorm examples in which the model was
built according to the view "needs". In my opinion that's a bad design ,
the model should represent the business data, not the way the view use
it.
2. When you can't use direct binding, the second best solution might be
vinding the view to helper functions. for example, if I have an intro
screen, and I want to show a welcome message according to the user's
sex, I would do something like that:
<mx:Label: text="{ getMessage(_mode.user.sex) }" />
That's pretty straight forward, but the problems comes when the link
between the view needs and the model data is implicit, I don't like my
view to guess what the state is according to the model, for example, I
would consider this to be bad:
<mx:Label text="{getMessage(_mode.user, _model.workflowState,
_model.isReady, _model.isPending)}" />
That's just too much responsibilties to put into the view.
That's kind of contradict what I stated in section 1, not to design the
model by the view, I think that might be the most difficult part for me,
to find the right balance between view responsibilities and model design
and would really like to hear what other people have to say about it...
3. If you really have to take an action after some data was initialized,
I would recommend not to use the Changewatcher if possible for it uses
strings to reference object chains, which is bad for refactoring.
for example, you have a model.files object that you listen to with the
change watcher, then you decide to change its name to imageFiles, you
won't get any compile time errors because it uses strings.
You can use Paul Williams observe
<http://weblogs.macromedia.com/paulw/archives/2006/05/the_worlds_smal.cf\
m> tag instead.
Well, that's it, it far away form being perfect, I'm sure there are some
better technique for certain situation, if any has some I would love to
hear about it...
Almog Kurtser,
http://www.kaltura.com <http://www.kaltura.com>
--- In flexcoders@yahoogroups.com, "rmarples" <[EMAIL PROTECTED]> wrote:
>
> As our product has gotten bigger, I have moved it from a standard
Model-View-Controller design to a
> more strict Cairngorm-like Model-View-Dispatcher-Command design. But
one particular aspect of it has
> left me a bit unsure as to the best practice. I'm hoping others can
share their views on this.
>
> There are various times when a Command needs to make a
"non-data-related" update to the view such
> as:
> - disabling/enabling buttons while a server operation runs
> - updating the focus of controls
> - changing component states
> - hiding/showing components
>
> We've had some debate about the best method to accomplish this. The
easy scenario is changing states
> because we can simply have a model variable that the view's
currentState property is data-bound to. So
> we can modify that model variable from within the Command which
indirect updates the view. But there
> are other situations that are more tricky. For example, we have a
login view with a username and
> password. We have a command that loads the stored username. If the
stored username is not found,
> we'd like to set the focus on the username textbox, whereas if the
username is found, then we want to
> put the focus on the password textbox. I don't believe you can set up
focus using data-binding (if you
> can let me know). So we have postulated several different solutions to
this, all of which work but we are
> trying to figure out which one is the most "correct" based on the
design pattern.
>
> 1. Set up a ChangeWatcher to watch the a model username variable, in
the handler set the focus based
> on whether that variable is null or not.
>
> 2. Dispatch an event from the command that the view listens to. This
is used to notify the view when the
> username variable has been populated and thus when it can run it's
focus logic.
>
> 3. Have the view object store a reference to itself in the model
somewhere so that the command can
> update it directly.
>
> I know this seems like a very granular point but I'm just looking for
the general practice in these types of
> situations because there are lots of them.
>
> Any thoughts?
>
> Ryan
>
