I was wondering whether ViewHelpers were correct if used in this scenario:

If my Command sets some data on the Model, I can make changes in my View easily (because I can bind the View to the Model), but what if I want to do something to the View, but I am not setting any values on the model?

(note: Should there ever be such a scenario, or does this mean I am using a Command where I shouldn’t?)

As the Command should not know anything about the View I considered using ViewHelpers. Thoughts welcomed.

We also avoided use of the ViewHelper for the views’ ‘helper methods’ (data-refresh logic, etc). Instead, we put the script in a separate file with the same name as the MXML file, but having the ‘.as’ extension. Then we just did a <mx:Script source='<<scriptFile>>’ /> to include that script file into the MXML file. This worked out well, because you avoid any overhead (although tiny) of registering the ViewHelper with the ViewLocator. Also, your script file, when included directly into the MXML file, becomes part of the same class as your MXML components, so all the UI components in the MXML are local (no more ‘view.___’ references), which also means you can make all your helper methods private. This results in a nice convention… UI component layout is in your MXML files, UI component interaction, event handling logic, and data refresh logic is in your AS files.

ViewHelpers, however, will take a project using them for me to really grasp their value.

I maintain the value of the View Helper when developing RIA with Flash; for brevity (and since neither you nor I are building RIA with Flash much anymore … welcome to the dark side by the way) I’ll omit the discussion here.

With Flex however, we found people over-using View Helpers beyond their original intent. Data-binding is a powerful mechanism in the Flex framework, that provides a neat way for our view to listen to the model. With View Helpers, developers would tend to get procedural about their view … using view helpers to set stuff on the view. With data-binding however, the view observes the model, and updates when the model changes.

That’s why we introduced the ModelLocator pattern; which isn’t a Core J2EE Pattern that we borrowed into Cairngorm, but is a pattern we introduced specifically into Cairngorm for building RIA with Flex. Using the ModelLocator, we have a singleton instance for State to be held, and for views to bind to that State. Commands can manipulate the model, views can bind to the model, decoupling of model and view is achieved.

We still use View Helpers where we need to ‘do stuff to the model before we render it in the view’, but the need for these classes greatly reduces when you apply the ModelLocator strategy correctly.

In my recent talk at MAX, I went through the Cairngorm Store application (current build, not the build currently in public domain) and covered off all these patterns. Just as soon as I’ve presented the same talk at MAX Greater China in Hong Kong this month, I’ll record it and put it online.