Re: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper
Hey Jesse, Any idea on why ViewHelper and ViewLocator classes are in Cairngorm 2 if they have been deemed un-beneficial? I myself felt obligated to see if there was a valid use for this based on the fact that they were included. Regards, Bjorn Schultheiss Senior Flash Developer QDC Technologies From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of JesterXL Sent: Tuesday, 4 July 2006 7:37 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper 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 d :: 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]com To: [EMAIL PROTECTED]ups.com 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]ups.com, 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
RE: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper
Guys, There's a lot of passion, misconception and misinformation around view helpers and their usefulness. However, a fact of life is that there ARE a number of projects in production where developers have made their own decisions to use ViewLocators and ViewHelpers, and in doing so have delivered successful projects. The project that was delivered for Fairfax in Australia (http://www.flexdaddy.info/2006/06/19/afr-access-one-of-the-largest-public-flex-apps-to-date/) is a great example of this, where Robin Hilliard felt that he gained from using the ViewLocator and ViewHelper pattern - I know Robin plans on writing this up at some point. Within Adobe Consulting, we see ViewHelper misused more than it's usefully used, and our introduction of the ModelLocator concept was our way of steering people to leveraging data-binding instead of abusing ViewHelpers beyond their intent. However, it's our responsibility as framework developers and maintainers, to not break all the legacy applications out there, which is why we've left that pattern in Cairngorm 2. Best, Steven Steven WebsterPractice Director (Rich Internet Applications)Adobe ConsultingWestpoint, 4 Redheughs Rigg, South Gyle, Edinburgh, EH12 9DQ, UKp: +44 (0) 131 338 6108 m: +44 (0)7917 428 947[EMAIL PROTECTED] From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Bjorn SchultheissSent: 05 July 2006 09:06To: flexcoders@yahoogroups.comSubject: Re: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper Hey Jesse, Any idea on why ViewHelper and ViewLocator classes are in Cairngorm 2 if they have been deemed un-beneficial? I myself felt obligated to see if there was a valid use for this based on the fact that they were included. Regards, Bjorn Schultheiss Senior Flash Developer QDC Technologies From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of JesterXLSent: Tuesday, 4 July 2006 7:37 AMTo: flexcoders@yahoogroups.comSubject: Re: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper 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 d ::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]comTo: [EMAIL PROTECTED]ups.comSent: Monday, July 03, 2006 5:01 PMSubject: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelperThanks for the responses guys,Dimitrios:Yes, the majority of my views
Re: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper
'Cause, there are those that like them and I'm sure Adobe is being responsive to the community, and ViewLocator's have their valid uses. - Original Message - From: Bjorn Schultheiss To: flexcoders@yahoogroups.com Sent: Wednesday, July 05, 2006 3:06 AM Subject: Re: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper Hey Jesse, Any idea on why ViewHelper and ViewLocator classes are in Cairngorm 2 if they have been deemed un-beneficial? I myself felt obligated to see if there was a valid use for this based on the fact that they were included. Regards, Bjorn Schultheiss Senior Flash Developer QDC Technologies From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of JesterXLSent: Tuesday, 4 July 2006 7:37 AMTo: flexcoders@yahoogroups.comSubject: Re: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper 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 d ::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]comTo: [EMAIL PROTECTED]ups.comSent: Monday, July 03, 2006 5:01 PMSubject: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelperThanks for the responses guys,Dimitrios:Yes, the majority of my views are updated through binding to theModelLocator. However, there are certain functions that are soleyview-related (like setFocus(), filtering a DataGrid, updating asearch parameter VO with view component values prior to executing asearch command), that imo don't merit creating a command toperform. These kind of functions could just be located in a scripttag inside the view. But, if the functions are numerous, the codebecomes more readable if a seperate class is used.Bjorn:I agree that a command shouldn't interrogate a view. That woulddefeat the encapsulation. For the most part though, the commandshould update the ModelLocator and the ModelLocator should updatethe view.Jesse:As always, you crack me up. In the situations that I mentionedabove, I assume that you are using a ViewLocator - uid approach.This is probably more efficient and centralized than usingViewHelpers. Besides, I really don't want to deal with Satanspawn. 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 aremore theoretical and best practice oriented. Good stuff to knowwhen scalability is an issue. Also, I'm still not sure what AlexUhlmann meant by "the ViewHelper adds and removes itself from theViewLocator". Guess I need to take a trip back to the Cairngormsource.Thanks again for your answers. I was hoping that Steven orAlistaire had time to chime in her
[flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper
Hi Tim, I am also considering the benefits of using viewHelpers. Here's what i got out of it. encapsulating all the logic necessary for interrogating and updating a particular View into a single helper class Why would the Command need to interrogate the View. A Command is always essentially created by the View and dispatched event data updates the Command. On Command remote handlers, the Command updates the model. I have been using explict setters on the view to initiate data-binding between model and view in mxml. Then it is View that is responsible for dispatching events throughout an application and that it is the View which will always drive the app. Regards Bjorn Schultheiss --- In flexcoders@yahoogroups.com, Tim Hoff [EMAIL PROTECTED] wrote: 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 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/
Re: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper
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 d :: 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: flexcoders@yahoogroups.com 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 flexcoders@yahoogroups.com, 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: flexcoders@yahoogroups.com
RE: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper
Tim, I've been in Ireland all of last week, and will be in France until the end of this coming week ... so my apologies that I've not been responding to your posts as you might otherwise hope; picked a great time to be out of office so much ! However, looks like the community as well as my fellow Adobe Consultants are keeping you somewhat on the straight and narrow ... normal service (for me at least) shall be resumed end of the week. Best of luck, Steven Steven WebsterPractice Director (Rich Internet Applications)Adobe ConsultingWestpoint, 4 Redheughs Rigg, South Gyle, Edinburgh, EH12 9DQ, UKp: +44 (0) 131 338 6108 m: +44 (0)7917 428 947[EMAIL PROTECTED] From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tim HoffSent: 03 July 2006 22:02To: flexcoders@yahoogroups.comSubject: [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]ups.com, "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]ups.com 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 SPONSORED LINKS
Re: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper
Also, whenever you are able to isolate a cohesive set of properties and methods from your view, you can extract it into a separate class which represents something real (what a pity that flexbuilder isn't capable to do this automatically). Tim, can you provide a code example, which necessarily needs a ViewHelper (or can benefit from it substantially)? Cheers, Ralf. On 7/3/06, JesterXL [EMAIL PROTECTED] wrote: 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. -- 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/
[flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper
No apologies necessary Steven. I appreciate you taking the time to respond at all. Safe travels, -TH --- In flexcoders@yahoogroups.com, Steven Webster [EMAIL PROTECTED] wrote: Tim, I've been in Ireland all of last week, and will be in France until the end of this coming week ... so my apologies that I've not been responding to your posts as you might otherwise hope; picked a great time to be out of office so much ! However, looks like the community as well as my fellow Adobe Consultants are keeping you somewhat on the straight and narrow ... normal service (for me at least) shall be resumed end of the week. Best of luck, Steven Steven Webster Practice Director (Rich Internet Applications) Adobe Consulting Westpoint, 4 Redheughs Rigg, South Gyle, Edinburgh, EH12 9DQ, UK p: +44 (0) 131 338 6108 m: +44 (0) 7917 428 947 [EMAIL PROTECTED] From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tim Hoff Sent: 03 July 2006 22:02 To: flexcoders@yahoogroups.com 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 flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , JesterXL jesterxl@ 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 TimHoff@ To: flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com 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
[flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper
Hi Ralf,
Here is a paired-down version of one of my ViewHelpers. Sorry about the formatting, it didn't copy over well. The searchView has a search text field, a RadioButtonGroup to select the search type, and two DateFields that can be used alone or in conjunction with the search field (depending on the search type selected). Some of this can be accomplished with validators. But, as you can see, there are different combinations of search options that need to be validated against each other. The functions like clearSearchDates() and searchFocus() are the ones that really seem to not require the creation of a command. Any advise is welcome. Also, in a case like this, would it be better to create a variable model:ModelLocator = new ModelLocator.getInstance();. It seems that using getInstance() for each of the individual variable is redundant and maybe slower.
Thank you,Tim Hoff
package org.ets.main.code.view.sideView.search {import flash.events.Event;import mx.utils.StringUtilimport mx.controls.Alert;import mx.events.CloseEvent;import org.nevis.cairngorm.view.ViewHelper;import org.nevis.cairngorm.control.CairngormEvent;import org.ets.main.code.control.ApplicationController; import org.ets.main.code.control.SearchEvent;import org.ets.main.code.model.ModelLocator;import org.ets.main.code.vo.SearchOptionsVO;import org.ets.main.code.vo.SearchSummaryVO;
public class SearchViewHelper extends ViewHelper {public function SearchViewHelper() {super();} //public function validateSearchOptions():void{ModelLocator.getInstance().statusMessage = "";view.txtSearch.errorString = "";view.searchFromDate.errorString = "";view.searchToDate.errorString = ""; // From and To Dates if (ModelLocator.getInstance().alertStatus == false) {if (view.radiogroupSearchOptions.selection.value == ModelLocator.SEARCH_TYPE_DATE_RANGE) { if ((view.searchToDate.text == ModelLocator.SEARCH_TO_DATE_LABEL) ||(view.searchToDate.text == "")) { ModelLocator.getInstance().statusMessage = ModelLocator.MESSAGE_SEARCH_DATES_REQUIRED; view.searchFromDate.errorString = ModelLocator.MESSAGE_SEARCH_DATES_REQUIRED; view.searchToDate.errorString = ModelLocator.MESSAGE_SEARCH_DATES_REQUIRED; } else if ((view.searchFromDate.text == ModelLocator.SEARCH_FROM_DATE_LABEL) || (view.searchFromDate.text == "")) { ModelLocator.getInstance().statusMessage = ModelLocator.MESSAGE_SEARCH_FROM_DATE_REQUIRED; view.searchFromDate.errorString = ModelLocator.MESSAGE_SEARCH_FROM_DATE_REQUIRED; } } if ((view.searchToDate.text != ModelLocator.SEARCH_TO_DATE_LABEL) (view.searchToDate.text != "") (view.searchFromDate.text != "") (view.searchFromDate.text != ModelLocator.SEARCH_FROM_DATE_LABEL)) { if (view.searchToDate.selectedDate view.searchFromDate.selectedDate) { ModelLocator.getInstance().statusMessage = ModelLocator.MESSAGE_SEARCH_FROM_DATE_LT_TO_DATE; view.searchFromDate.errorString = ModelLocator.MESSAGE_SEARCH_FROM_DATE_LT_TO_DATE; } } // txtSearch Stringif (view.radiogroupSearchOptions.selection.value != ModelLocator.SEARCH_TYPE_DATE_RANGE) { var txtSearch : String = StringUtil.trim(view.txtSearch.text); if (txtSearch == "") { view.txtSearch.text = "";ModelLocator.getInstance().statusMessage = ModelLocator.MESSAGE_SEARCH_STRING_REQUIRED; view.txtSearch.errorString = ModelLocator.getInstance().statusMessage } } // Search or Display Error Message if (ModelLocator.getInstance().statusMessage == "") { search();} else { ModelLocator.getInstance().alertStatus == true Alert.show(ModelLocator.getInstance().statusMessage,ModelLocator.getInstance().sideViewTitle, Alert.OK, null, alertListener, null, Alert.OK);} }// alertStatus == false }
//public function search():void{ var searchOptionsVO : SearchOptionsVO = new SearchOptionsVO(); var searchSummaryVO : SearchSummaryVO = new SearchSummaryVO(); var searchMessage : String; searchMessage = view.radiogroupSearchOptions.selection.label; if (view.radiogroupSearchOptions.selection.value == ModelLocator.SEARCH_TYPE_DATE_RANGE) { searchMessage += " "; searchMessage += view.searchFromDate.text; searchMessage += " to "; searchMessage += view.searchToDate.text; } else { searchMessage += " = "; searchMessage += view.txtSearch.text.toUpperCase(); if ((view.searchToDate.text != ModelLocator.SEARCH_TO_DATE_LABEL) (view.searchToDate.text != "")) { searchMessage += " - "; searchMessage += view.searchFromDate.text; searchMessage += " to "; searchMessage += view.searchToDate.text; } } searchOptionsVO.searchMessage = searchMessage; searchOptionsVO.searchType = view.radiogroupSearchOptions.selection.value.toString(); searchOptionsVO.searchString = view.txtSearch.text; if (view.searchFromDate.text.toString() == ModelLocator.SEARCH_FROM_DATE_LABEL){ searchOptionsVO.useDates = 'No' } else { searchOptionsVO.useDates = 'Yes' } searchOptionsVO.searchFromDate =
RE: [flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper
Hey Tim, You wrote like setFocus(), filtering a DataGrid, updating a search parameter VO with view component values prior to executing a search command Those kinds of things I do in an AS script block for the particuliar component. Like Jesse mentioned, I too used to created ViewHelpers that used to just have all the code related to a particuliar view, when in fact I should have simply put everything in a script block and it would have done exactly the same thing. The other thing to remember in Flex development is that you are creating components (most of which are views), so make sure you creating the smallest possible component so you, so the code in the script block isn't actually that much. Plus it makes the component reusable and easy to maintain. Hope that helps, Dimitrios Optimal Payments Inc. -Original Message- From: flexcoders@yahoogroups.com on behalf of Tim Hoff Sent: Mon 7/3/2006 5:01 PM To: flexcoders@yahoogroups.com 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 flexcoders@yahoogroups.com, 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: flexcoders@yahoogroups.com 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 -- WARNING --- This electronic message and its attachments may contain confidential, proprietary or legally privileged information, which is solely for the use of the intended recipient. No privilege or other rights are waived by any unintended transmission or unauthorized retransmission of this message. If you are not the intended
[flexcoders] Re: Cairngorm2: ViewLocator - ViewHelper
Yes, I agree. If you look at the post that I sent to Ralf, you'll see that there is a lot of AS in the ViewHelper. I started with a script tag inside the view and moved it to a ViewHelper for readability. That way if I needed to change the way the view looked, I would edit the view. If I wanted to change the functionality, I would edit the ViewHelper. I don't know, it seems like apples and oranges. I'm just interested in different opinions here. I appreciate your feedback. -TH --- In flexcoders@yahoogroups.com, Dimitrios Gianninas [EMAIL PROTECTED] wrote: Hey Tim, You wrote like setFocus(), filtering a DataGrid, updating a search parameter VO with view component values prior to executing a search command Those kinds of things I do in an AS script block for the particuliar component. Like Jesse mentioned, I too used to created ViewHelpers that used to just have all the code related to a particuliar view, when in fact I should have simply put everything in a script block and it would have done exactly the same thing. The other thing to remember in Flex development is that you are creating components (most of which are views), so make sure you creating the smallest possible component so you, so the code in the script block isn't actually that much. Plus it makes the component reusable and easy to maintain. Hope that helps, Dimitrios Optimal Payments Inc. -Original Message- From: flexcoders@yahoogroups.com on behalf of Tim Hoff Sent: Mon 7/3/2006 5:01 PM To: flexcoders@yahoogroups.com 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 flexcoders@yahoogroups.com, JesterXL jesterxl@ 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 TimHoff@ To: flexcoders@yahoogroups.com 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
