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 > ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/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/
