Cairngorm is an application framework written by Iteration::Two for Macromedia Flex.
About the same time I started learning Flex, I started getting into learning ARP, a light-weight framework originally created for Flash. ARP has a lot in common Cairngorm. There was some contention between Aral, ARP’s creator, and Steven one of Cairngorm’s contributors on a few points.
One of which was ViewLocators/ViewHelpers. I tried for ages to get a frikin simple, 1 sentence description on what the hell they did. I had the same problem with Business Delegate. I fixed that by using a business delegate in a project, and seeing how they could help.
Aral had some notes in the ARP documentation about them ViewLocator/ViewHelpers, but they didn’t really give a lot of detail to why.
Steven responded to me personally, twice, as well as a couple times on public email lists and my blog; very long, and detailed responses.
I still didn’t get it.
Aral and Steven got into it on Flexcoders at one point, and Aral had a well formed counter-point.
I still didn’t get it.
I even asked my boss, Jeremy Bruck, a smart CTO. He gave me a 2 sentence answer, with an anology.
Still didn’t get it.
I downloaded the framework and read the docs, but really saw no point.
SO, I’m in the company office today because I needed to have some meetings with the boss and co-workers on a project I’m working on as well as a have one of their admins set my computer up with ColdFusion & friends. One of their developers, Dave Buhler, is using Cairngorm now in one of their projects.
I assualted him with questions, and he gives me a 1 sentence reply. I warp his words into a counter-quote, and he confirmed what I said as correct. HOLY SHIT, I GOT IT!
“A ViewHelper is a class that calls methods on whatever View it’s associated with. ViewLocator is a Singleton that stores all of your ViewHelpers by name, like ‘MyLoginFormViewHelper'”.
God, I should write a book; “Cairngorm for Flash Developers.” Suddenly it makes soo much sense as to why you would actually do that on a project that had a few team members with A LOT of views.
Steven, why in the hell didn’t you say that in the first place?
The jury is still out on how I feel about them, though. I’ve never had problems finding my views, nor calling methods on them; but that’s because it’s usually me, or me and 2 dudes that work with me, keeping in constant communication. I can see how if I had a lot of developers working on the same project where I was not in constant contact with them, and where there were a plethora of views where ViewHelpers and a ViewLocator would help.
I’ll battle test her in the next few weeks to see if I dig it or not.
Interesting, I too didn’t understand what ViewHelpers and ViewLocators were. I will have to look into some more examples and digest some more technical discussion to decide whether they suit me.
Currently in my project I created a ViewUpdateController, which was basically an event dispatcher. The various Controllers would instruct the ViewUpdateController to dispatch the appropriate event, and all the View classes would listen for the events they wanted to deal with. It did mean that there was a level of functionality in the Views (although really just redrawing), but I felt it did abstract the View redrawing from the Controllers well.
i don’t suppose you have those links / arguments handy for reference?
-erik
‘A ViewHelper is a class that calls methods on whatever View it’s associated with.’ — But why would you want a class to do that? Why not just call the methods directly? The way you’ve explained it, implies, there is a one-to-one correspondance between Views and ViewHelpers and that means 2 classes for every view. What is the benefit of creating 2 classes fro every view?
Welcome to the club Jesse. I had a hard time understanding these 2 as well, but they make sense in some situations. I now understand why Aral was not advocating them and on the other hand understand why you would use them.
@chris: in smaller projects where you work alone, or with 2-3 members, there is probably no need to use ViewHelpers. Why? Because the GUI dev is also the one that writes the command, etc and he knows how the views are structured. What if you were on a bigger team and each was responsible for his own part (views, commands, etc). The guy that writes the commands would need to know exactly how the view is structured. And what if the view dev changes the implementation of the views, they get another parent form, or some new subforms, the names change, etc. In that case, the GUI guy would just alter the ViewHelpers to reference the views in the new way. He doesn’t have to know about commands, he does not have to change the code in the commands and can’t break any code. That personally makes sense to me in big projects, but again in small projects they are probably more work than needed.
What do you think?
Hey man, just a heads up: We still don’t have ViewHelpers or a ViewLocator in Arp (and probably won’t in the coming days) but we did find using a ModelLocator to be very helpful in our latest Project (it should be there in the Arp SVN tree.) In fact, I’ve made quite a few Flex additions to Arp that I haven’t had the chance to release (this is AS2/Flex 1.5) but these make certain important real-world things much easier (like working with external forms in a very elegant manner.) Expect more once I get through the killer deadline we have for this project on Monday.
Jesse … so glad you finally saw the light, a point release after we kinda stopped advocating you use View Helpers so much with Flex.
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.
Yeah, I stole ModelLocator for use in ARP a long time ago, very easily seeing it’s value.
ViewHelpers, however, will take a project using them for me to really grasp their value.
Grant… I’m right there with you. I did essentially the same thing on a fairly large Flex project (using Cairngorm) that was recently completed. In working with a team of 3 concurrently developing the same Flex app, the event-driven view approach seemed to work much better than a ViewHelper/ViewLocator approach. We actually started with the latter, and ended up refactoring to the former.
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.
First, sorry for digging up such a very old post(!) – there doesn’t seem to be a great deal of info posted about ViewHelpers.
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.
http://weblogs.macromedia.com/paulw/archives/2007/11/presentation_pa_4.html