Hi, anzer (hope it is your nickname) I have been using the cairngorm framework in my university's project. Latest version, 2.2.1 beta, introduces the ViewLocator and ViewHelper class. It makes possibility to access control in view-tier from command logic.
Anyway, I also found the problem in using this pattern. The viewhelper instance throws null exception while I require an access to control. But it's work well if you manually cast in to thier type ( like (SampleApp) from SampleApp.mxml ) May be, you could found the solution to solve null exception for my. ;) --- In [email protected], "mailtoanzer" <[EMAIL PROTECTED]> wrote: > > I am also looking for the beast practice for Command-View communication. > Currently we are using model variables and setter functions in the > View to achieve this. > > > --- In [email protected], "rmarples" <rmarples@> 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 > > >
