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" <[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 >
