Speaking for Steven, but the reason they espoused using ModelLocator over ViewHelpers was a few reasons. First off, many people felt the need to create ViewHelpers for every View. This was ridicolous; no View could ever do anything useful but instantiate GUI components, and register for events. You had no clue WHAT that View could do. Suddenly you're code base basically doubled for extremely little gain.
Secondly, most people utilized ViewHelpers with ViewLocator instead of the actual View's. While this was nice, no one ever implemented strong typing, thus defeating the purpose of casting as ViewHelper describing what the View could do. Third, you wrote more code for no gain. Some people would even put code in both the MXML View and ViewHelper, further compounding the issue of "what's really being seperated here". In all fairness, I come from a Flash background where you wrote classes. These classes were your View. You can do the same thing in Flex; write your class to extend Canvas instead of using a root Canvas tag; same thing. To me, organizing code is 2nd nature. MXML + embedded Script tags were just a wonderful next step. My code changes never broke my GUI changes and vice versa. For some reason, it seems people can't fathom the thought of ActionScript in MXML files. That's just absurd; you can see what the GUI is AND does in the same. Go look at the source code; all kinds of controls draw themselves and perform actions. This isn't rocket science, it's a fuggin' form for crying out loud. The other option of using an external script file for the script tag is just as bad. You have to define controls and other buttons again, defeating the use of the ID control concept which helps shield your code from being broken when you change your GUI. :: que Carlos Mencia duh dah daaaa :: Bottom line, MXML components are extremely portable and encapsulated with ActionScript inside them. Granted, there are still people who will write "components" with ModelLocator's littered amongst them vs. expousing public properties and methods to set the data instead... but that's the developers fault, not MXML's. MXML is just a class... it's ok to write properties and methods in a class... seriously, it's ok. :: whips out a bag of teddy bears to hand out just in case :: ----- Original Message ----- From: "Tim Hoff" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, July 03, 2006 5:01 PM Subject: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper Thanks for the responses guys, Dimitrios: Yes, the majority of my views are updated through binding to the ModelLocator. However, there are certain functions that are soley view-related (like setFocus(), filtering a DataGrid, updating a search parameter VO with view component values prior to executing a search command), that imo don't merit creating a command to perform. These kind of functions could just be located in a script tag inside the view. But, if the functions are numerous, the code becomes more readable if a seperate class is used. Bjorn: I agree that a command shouldn't interrogate a view. That would defeat the encapsulation. For the most part though, the command should update the ModelLocator and the ModelLocator should update the view. Jesse: As always, you crack me up. In the situations that I mentioned above, I assume that you are using a ViewLocator - uid approach. This is probably more efficient and centralized than using ViewHelpers. Besides, I really don't want to deal with Satan spawn. Care to share a small sample of your approach? All in all, this isn't a huge issue. Out of my current 300 views, I've only found the need to use three ViewHelpers. My questions are more theoretical and best practice oriented. Good stuff to know when scalability is an issue. Also, I'm still not sure what Alex Uhlmann meant by "the ViewHelper adds and removes itself from the ViewLocator". Guess I need to take a trip back to the Cairngorm source. Thanks again for your answers. I was hoping that Steven or Alistaire had time to chime in here, but I realize that they are very busy these days. Cheers, Tim Hoff --- In [email protected], "JesterXL" <[EMAIL PROTECTED]> wrote: > > ViewHelpers == spawn of satan. Nothing here but bloated code. "Seperation > of concerns" doesn't count here; it's just something they say to make > themselves feel better by using them. > > ViewLocators, to me are only justified in extreme use cases. Having other > View's, or even Commands specifically telling other views to do certain > things are bad practice, but I have seen times where there is just no other > way. The rest of the time, databinding and combinations of getter / setters > should accomplish what you want. While their use should be discouraged, > I'll be the first to admit they are useful and lifesavers when you need > them. > > > ----- Original Message ----- > From: "Tim Hoff" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Monday, July 03, 2006 6:05 AM > Subject: [flexcoders] Cairngorm2: ViewLocator - ViewHelper > > > I've recently been toying with the concepts of ViewHelper vs. > ViewLocator. Alex Ulmann posted, "the ViewHelper adds and removes > itself from the ViewLocator", in his Cairngorm 2 (for Flex 2) - > Overview and Migration Path. I haven't seen any examples yet that > illustrate this method. Understandably, the example pool and > documentation for this kind of thing is small but growing. So, I was > wondering if the authors of Cairngorm had any advise/guidance for this > topic. Of course it's a matter of scale, but in an enterprise > application, what is recommended as best practice for the use of > ViewLocator and/or ViewHelpers? I'm sure that there are forthcoming > books that cover this area, but feedback here might promote better > understanding. > > Best regards, > Tim Hoff > > > > > > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Search Archives: http://www.mail-archive.com/flexcoders% 40yahoogroups.com > Yahoo! Groups Links > -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links ------------------------ Yahoo! Groups Sponsor --------------------~--> Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/nhFolB/TM --------------------------------------------------------------------~-> -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
