I recently found the need for my command to effect a change in my view, specifically, I am loading a config file into my application, once that config has loaded I wanted to popup a login screen on the main application view. The way I have this working now I have my LoadConfigCommand request the xml config file through a delegate then respond back to the commands result handler. LoadConfigCommand’s result method needs to then popup a login window. This could easily be solved by using

1
2

     var appReference:DisplayObject = DisplayObject( Application.application );
     var popup:IFlexDisplayObject = PopUpManager.createPopUp( appReference, Login, true );

but I am not particularly partial to using Application.application references as it has gotten me into trouble a few times before. While this is a valid solution to this, it doesnt fit the needs or solve the problem of talking to my view through my command, at best this is only a bridge to my view, and as more complex problem arise in this realm this quickly becomes a brittle if not unmanageable solution.

So where does this leave me? Research. I looked around, for what others have been doing to solve this problem, and came across a few very interesting approaches. I came across Jesse Warden’s post on ViewHelpers in Cairngorm to see if I could access my views using the ViewHelpers ViewLocator. I went ahead and registered my views but when it came time to accessing the methods of my views it became apparent that I would need to cast my viewLocator with my View itself: Projects( ViewLocator.getInstance().getViewHelper(“projectsHelper”) ).doLogin(); which to me seems contrary. To use this solution I will be going against to core principals of mvc and cairngorm by introducing a reference of my view into my command, and for that matter for this example I might as well just do: Projects.doLogin() as this is essentially the same solution to this problem. Next I read about Alex’s post on creating a popup window in Cairngorm. Seems like this will work. I started reading more about it, and his usage of the Observer pattern to listent to changes in the model. Alex writes that he is setting a boolean value in his model from his command, and listening for this change through ObserveValue. Again this is a perfectly viable solution to this problem as well, however the more complex the problem becomes, and the more I need to listen to changes in my model to effect changes in my view this will quickly become a cluttered and almost unidentifiable clutter of boolean values in my model. Besides my view may need to have multiple states which surpass the simple values of True and False.

So im still stumped at this point… I message Paul over at AC to get his views on the matter and hopefully gain some knowledge on the best solution for this. My question to him was “how do I speak to a view from a command”. His logic is, well… logical. He told me that in architectural decisions if it doesn’t feel right, it inst right. Think about what the popup represents, a view state change. State change being the optimal word here. Since this is a state change and state is maintained in the model its perfectly inline to have my view listen to my model for a change that is set by my command. This is similar to Alex’s recommendation however by not using boolean values and binding the view using mx:Binding instead of ObeserveValue I am able to listen to more profound change values such as var applicationState:String = “preloading” and then wrap this bound value to a switch case that my view will decide what to do with when a change has been made. The differences between the two paths, from my view, is that Alex’s solution forces the model to maintain distinct state values for each and every change so that in the event that your single view may have 5 or 6 or more changes then you would have 5 or 6 or more corresponding state values of type boolean in your model that your views would listen to individually whereas by having a single state variable I can write in as many state changes as I need and match them on the switch case in my view.

So lets think about this a bit more abstractly. lets remove the popup example as we have many ways of achieving a solution to this. Lets think about this example: I have an image viewer / editor application, my main application view has a collapsible toolbar that is defaulted to open. The user clicks on the preview button which goes through the Cairngorm daisy chain to get to my command. once at my command I want to hide a few things and show a few things, including hiding my toolbar which at this point is no longer needed the user is now previewing. From my command, using the solution above, I have set a variable in my model var viewMode:ViewModes = ViewModes.EDITOR; which from my command I will set a from EDITOR to PLAYER so my model will now show viewMode:ViewModes = ViewModes.PLAYER. My main application view is bound to this variable using mx:Binding and is set to a setter in the same view. The setter goes through a quick switch case to determine what to do based on the value set and then reacts accordingly, in this instance it hides the toolbar.

My issue here was that I felt that there must be a way to communicate directly to the view on low levels requests, things that didnt seem logical to clutter the model with, maybe some variation of the ViewLocator might have worked in this instance to gain access to the view for such requests. Well Paul broke this down in a very logical way that to me seems like a good rule of thumb for this problem:

If there is a material change in state
If several views would need to respond
Then stick it in the model and bind currentState to the var

If its just in 1 component (for example changing the text on a submit button while waiting for a response)
If it seems just plain pernickity
Then have that logic in the view

MOST OF ALL:
design and architect and develop in such a way that allows you to change your mind

So my take on this is that, when I need to talk to my view all the way from my command, I need to:

First identify why I want to talk to my view in the first place

• Is this something the View can handle on its own
• Does this demand to wait for something to happen from the command
• Is this a state change
• Will more then one view listen to this change

Write my command’s result to set the change variable in the model
Listen to this change through Binding in the various views that will be effected by the change

And there you have it, through good clean code and a bit of organization my model will be filled with state as it well should be and my various and infinite views will listen to those states and react to the changes set by my commands.