Re: Option for NavigationHandler to support viewIds as outcome
Hi again, Thank you very much for your opinions and insights. I understand now that there are doubts supporting such a feature. What I understood these are mainly about encouraging users to use not best practise approaches. IMO this is for sure a duty of teachers or books, but a webdevelopment framework? I'm not so sure about that. I think users should be provided with as much flexibility as possible rather than trying to force them to share all our philosophy. And also this is as martin and mattias pointed out usable in small scale applications tiny prototypes and so on. Seeing competitions as ruby on rails and php features like that could make JSF also more attractive for prototyping. But thats just my opinion and I'm for sure not starting to do something not approved by the community again. So what is the desicion? 1.) Seperate NavigationHandlerImpl 2.) Configurable Option 3.) Custom NH code in the wiki with a discouraged note 4.) Not at all regards Ernst On 10/30/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I am really fine with adding this NH_Impl to Tomahawk. Here are my rules for that: -It is not used by default! -it is not configured to a bogus web.xml context param -it should be used in the app's faces-cfg.xml file the cons and pros are like Do you like Rails, or not :) Well, somethimes that makes sense; sometimes not. The fun is, that you can choose! Just put it to your faces-cfg. I have heard that requirement before that thread. I don't think it's a not understanding JSF thing. Sorta lazy guy approach ... -M On 10/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/30/06, Mario Ivankovits [EMAIL PROTECTED] wrote: In reality there is a dependency between two pages, there is a silent contract how to prepare the managed beans so that the destination page knows what to display (and I think the f:param stuff is useless here). So more often than not you'll use a updateActionListener to set stuff on the destination backing bean. And voilla, you'll have hard dependency between these two pages. This is an important point, no matter how you architect your navigation. shameless-plug That is why Shale's view controller has a prerender() method ... you are encouraged to use that method in the destination page to pull data that this page needs out of the model, rather than having the origin page push data into the destination page (or some request scoped objects whose names are known to both). That way, coupling is minimized to something like passing primary keys -- and I like the convention of always passing, say, a customerId, in the same place throughout the application (independent of particular pages), to minimize direct coupling between any two particular pages. This approach also makes it *much* easier for your application to support bookmarkable GET URLs that pass primary keys with request parameters. /shameless-plug Craig -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Option for NavigationHandler to support viewIds as outcome
Hi! 1.) Seperate NavigationHandlerImpl IMHO, this is a must! I think we should *not* implement stuff which silently changes/enhances the behaviour - especially in myfaces-impl!! The TCK might forbid this change anyway ... 2.) Configurable Option not required, as everyone can configure this NH in faces-config.xml. 3.) Custom NH code in the wiki with a discouraged note This might be a good compromise. 4.) Not at all I do not mind ;-) 5) Add the new NH to the sandbox (but not configured by default) I like it to put stuff to the sandbox first and see if the community is willing to use them something like the time will tell if its worth. Ciao, Mario
Re: Option for NavigationHandler to support viewIds as outcome
As an outcome of this discussion, I'm +1 for 1. regards, Martin On 10/31/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! 1.) Seperate NavigationHandlerImpl IMHO, this is a must! I think we should *not* implement stuff which silently changes/enhances the behaviour - especially in myfaces-impl!! The TCK might forbid this change anyway ... 2.) Configurable Option not required, as everyone can configure this NH in faces-config.xml. 3.) Custom NH code in the wiki with a discouraged note This might be a good compromise. 4.) Not at all I do not mind ;-) 5) Add the new NH to the sandbox (but not configured by default) I like it to put stuff to the sandbox first and see if the community is willing to use them something like the time will tell if its worth. Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Option for NavigationHandler to support viewIds as outcome
On 10/31/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! 1.) Seperate NavigationHandlerImpl IMHO, this is a must! I think we should *not* implement stuff which silently changes/enhances the behaviour - especially in myfaces-impl!! The TCK might forbid this change anyway ... +1 ! 2.) Configurable Option not required, as everyone can configure this NH in faces-config.xml. right! adding stuff to the web.xml for that is blech! 3.) Custom NH code in the wiki with a discouraged note This might be a good compromise. like we do with the JBoss stuff ? I don't mind that 4.) Not at all I do not mind ;-) 5) Add the new NH to the sandbox (but not configured by default) I like it to put stuff to the sandbox first and see if the community is willing to use them something like the time will tell if its worth. Yes, my understanding is that EVERY new Tomahawk stuff goes to Sandbox first. Components AND framework features. Go ahead Ernstl -M Ciao, Mario -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Option for NavigationHandler to support viewIds as outcome
I think we should be very careful about adding a feature that encourages people to drift away from the spec. I agree with the reasons that Craig laid out for why the outcomes behave the way they do now. Its true that its not our job to force people to do follow certain standards. Its also true that we shouldn't be putting code into a shared codebase that serves the needs of a minority of the participants. I am not hearing a lot of enthusiastic support for this idea. Reactions are ranging from as long as its optional to this has no place in JSF. I think we should keep this out of Tomahawk. People are free to do whatever they want with their own code so this seems to be a case where that is most appropriate. Use it in your personal code and writeup a wiki or blog entry on it if you want to share it. Not everything has to make it in and it seems like enough people have reservations about it. My .02 Sean On 10/31/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 10/31/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! 1.) Seperate NavigationHandlerImpl IMHO, this is a must! I think we should *not* implement stuff which silently changes/enhances the behaviour - especially in myfaces-impl!! The TCK might forbid this change anyway ... +1 ! 2.) Configurable Option not required, as everyone can configure this NH in faces-config.xml. right! adding stuff to the web.xml for that is blech! 3.) Custom NH code in the wiki with a discouraged note This might be a good compromise. like we do with the JBoss stuff ? I don't mind that 4.) Not at all I do not mind ;-) 5) Add the new NH to the sandbox (but not configured by default) I like it to put stuff to the sandbox first and see if the community is willing to use them something like the time will tell if its worth. Yes, my understanding is that EVERY new Tomahawk stuff goes to Sandbox first. Components AND framework features. Go ahead Ernstl -M Ciao, Mario -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Option for NavigationHandler to support viewIds as outcome
On 10/31/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! 1.) Seperate NavigationHandlerImplIMHO, this is a must! I think we should *not* implement stuff whichsilently changes/enhances the behaviour - especially in myfaces-impl!!The TCK might forbid this change anyway ... 2.) Configurable Optionnot required, as everyone can configure this NH in faces-config.xml.In particular, if you decide to implement this feature, consider packaging it inside a separate JAR file with its own embedded META-INF/faces- config.xml file that defines the custom navigation handler. That way, it is self configuring -- to use the feature, just drop the JAR into your app.Craig 3.) Custom NH code in the wiki with a discouraged noteThis might be a good compromise. 4.) Not at allI do not mind ;-)5) Add the new NH to the sandbox (but not configured by default) I like it to put stuff to the sandbox first and see if the community iswilling to use them something like the time will tell if its worth.Ciao,Mario
Re: Option for NavigationHandler to support viewIds as outcome
2.) Configurable Option not required, as everyone can configure this NH in faces-config.xml. In particular, if you decide to implement this feature, consider packaging it inside a separate JAR file with its own embedded META-INF/faces- config.xml file that defines the custom navigation handler. That way, it is self configuring -- to use the feature, just drop the JAR into your app. You are right with that (that also what you do in Shale - Tiles for instance). Shale Tiles is different. It makes sense in that world to do that. For this NH, we should ensure to have it not that convenient to get it working. They should need to put it manually in their faces-cfg.xml, to be aware they know what they are doing. By adding random-myfaces-xxx jars you can cause confusion to the users. Adding it to the faces-cfg.xml is sorta marker interfaces pattern (sure a poor one :)) Thanks! Matt Craig 3.) Custom NH code in the wiki with a discouraged note This might be a good compromise. 4.) Not at all I do not mind ;-) 5) Add the new NH to the sandbox (but not configured by default) I like it to put stuff to the sandbox first and see if the community is willing to use them something like the time will tell if its worth. Ciao, Mario -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Option for NavigationHandler to support viewIds as outcome
Hmm, sounds interesting, what exactly would you have in mind, something like a Callback for additional security checks which receives the viewId and then can check wheather or not access is allowed and return a boolean or so? On 10/30/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ernst, you also wanna check some of the *extensions* in the MyFAcesNH_Impl for accessing navigation cases. It is important in security cases to *check* navigation cases ... so your impl could benefit from that ! On 10/29/06, Ernst Fastl [EMAIL PROTECTED] wrote: You're right, an alternate NavigationHandler shipped with MyFaces is probably the better choice let's go with that approach. thanks for your ideas On 10/29/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: 2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes Sorry don't get your point here, if an action returns a misspelled outcome or a misspelled viewId you would not want to navigate in both cases right? I think he means the 404 error, ... However, I kinda like stuff like that, but not configurable! We had had enough fun with bogus features like dummyForm. We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if sb. really really want that, use that particular NH. just my $0.02 -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Option for NavigationHandler to support viewIds as outcome
look at the nh_impl. you see it :) On 10/30/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hmm, sounds interesting, what exactly would you have in mind, something like a Callback for additional security checks which receives the viewId and then can check wheather or not access is allowed and return a boolean or so? On 10/30/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ernst, you also wanna check some of the *extensions* in the MyFAcesNH_Impl for accessing navigation cases. It is important in security cases to *check* navigation cases ... so your impl could benefit from that ! On 10/29/06, Ernst Fastl [EMAIL PROTECTED] wrote: You're right, an alternate NavigationHandler shipped with MyFaces is probably the better choice let's go with that approach. thanks for your ideas On 10/29/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: 2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes Sorry don't get your point here, if an action returns a misspelled outcome or a misspelled viewId you would not want to navigate in both cases right? I think he means the 404 error, ... However, I kinda like stuff like that, but not configurable! We had had enough fun with bogus features like dummyForm. We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if sb. really really want that, use that particular NH. just my $0.02 -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Option for NavigationHandler to support viewIds as outcome
I definitely think Ernst's idea is a good one - and I do think that a configuration-parameter for adding this would be optimal. The dummy-form stuff was not compatible with the RI, overwriting a navigation-handler in tomahawk, behaving differently if a configuration parameter is set; would of course be! regards, Martin On 10/30/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: look at the nh_impl. you see it :) On 10/30/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hmm, sounds interesting, what exactly would you have in mind, something like a Callback for additional security checks which receives the viewId and then can check wheather or not access is allowed and return a boolean or so? On 10/30/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ernst, you also wanna check some of the *extensions* in the MyFAcesNH_Impl for accessing navigation cases. It is important in security cases to *check* navigation cases ... so your impl could benefit from that ! On 10/29/06, Ernst Fastl [EMAIL PROTECTED] wrote: You're right, an alternate NavigationHandler shipped with MyFaces is probably the better choice let's go with that approach. thanks for your ideas On 10/29/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: 2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes Sorry don't get your point here, if an action returns a misspelled outcome or a misspelled viewId you would not want to navigate in both cases right? I think he means the 404 error, ... However, I kinda like stuff like that, but not configurable! We had had enough fun with bogus features like dummyForm. We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if sb. really really want that, use that particular NH. just my $0.02 -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: Option for NavigationHandler to support viewIds as outcome
If you specify the navigation in the faces-config.xml, then you are already using a configuration parameter... I this case you would not have to define another web-context parameter... The idea sounds like the DefaultServlet from Tomcat... easy to become addited to ;) regards Alexander -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 9:52 AM To: MyFaces Development Subject: Re: Option for NavigationHandler to support viewIds as outcome I definitely think Ernst's idea is a good one - and I do think that a configuration-parameter for adding this would be optimal. The dummy-form stuff was not compatible with the RI, overwriting a navigation-handler in tomahawk, behaving differently if a configuration parameter is set; would of course be! regards, Martin On 10/30/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: look at the nh_impl. you see it :) On 10/30/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hmm, sounds interesting, what exactly would you have in mind, something like a Callback for additional security checks which receives the viewId and then can check wheather or not access is allowed and return a boolean or so? On 10/30/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ernst, you also wanna check some of the *extensions* in the MyFAcesNH_Impl for accessing navigation cases. It is important in security cases to *check* navigation cases ... so your impl could benefit from that ! On 10/29/06, Ernst Fastl [EMAIL PROTECTED] wrote: You're right, an alternate NavigationHandler shipped with MyFaces is probably the better choice let's go with that approach. thanks for your ideas On 10/29/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: 2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes Sorry don't get your point here, if an action returns a misspelled outcome or a misspelled viewId you would not want to navigate in both cases right? I think he means the 404 error, ... However, I kinda like stuff like that, but not configurable! We had had enough fun with bogus features like dummyForm. We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if sb. really really want that, use that particular NH. just my $0.02 -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Option for NavigationHandler to support viewIds as outcome
On 10/29/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hi!At the moment when no navigation case for an outcome is foundthe navigationHandler decides to stay at the same view. I thinkan option for web.xml would be useful to tell the navigationHandlerif no navigation case for an outcome is found, but the outcome matches a viewId to navigate to this view id.This idea was mainly driven by a lot of jsf-projects where I saw for eachview id:navigation-rulefrom-view-id*/from-view-id navigation-casefrom-outcomeviewId/from-outcometo-view-id/viewId.xhtml/to-view-idredirect//navigation-case ...which seems kind of unnecessary to mewhat do you think about that?I think that the developers of projects like that did not actually understand the reasoning behind the standard JSF approach to navigation. The basic theory is that an action method should return a *logical outcome* -- a string that says this is what happened, not a string that says go to this page next. That decision should be left to the architect who is gluing things all together. In particular, you should *want* to have the ability to remodel your view identifiers namespace, *without* having to go modify every single action method that returns a view id instead of a logical outcome. Consider the following use case to understand what's going on here. Lots of web sites have search text fields (like Google's search text field) that can be used to select the relevant database information. Let's assume, for the purposes of discussion, that such a text field exists to select a customer from your database of current customers. Next, let's look at this issue from the viewpoint of the developer who is writing the action method that responds to a user entering a value into the search field. If you are following good application design principles, this person will *not* know (or care) about what page should be displayed next. Instead, he or she will be focused on the fact that there are three logical outcomes that can result from a database search based on criteria specified in the search field: * No matching results were found.* Exactly one matching result was found.* More than one matching result was found.In a very simple minded application (or a RAD-developed prototype), you might be satisfied with only doing one thing in all three cases. In a user-friendly app, on the other hand, you might want to react like this: * No results -- show the search criteria page again with a message saying I'm sorry, no matches were found -- please refine your search criteria.* Exactly one result -- go directly to the next step in the user conversation, having selected a particular master record.* More than one result -- go to a page that lists the available matches and lets the user select the desired one.The key issue here ... THE DEVELOPER WRITING THE ACTION METHOD FOR THE SEARCH SHOULD NOT NEED TO KNOW WHAT HAPPENS NEXT. The important responsibility is to report this is what happened (one of the three logical outcomes). It's up to the rest of the application to react to this event. And, over the lifetime of the application, this reaction might change -- but you should *not* have to go back and do the original code over again. Given this background, I believe that the proposed feature here is *not* a good idea. It is counter to the basic philosophy behind the navigation handler architecture that the JSF spec defines. regardsErnstCraig McClanahan
Re: Option for NavigationHandler to support viewIds as outcome
Hi Craig, you have been argumenting into this direction before, and I'm sorry to disagree completely. What JSF does in the standard is good for projects where you have this necessity of different roles for page development and back-end development. Generally - for small projects, and the majority of web-projects are still small projects, the person writing the navigation-handling code, the page, and the backing-bean will be the same, so why not give them the ability to have a convention-over-configuration approach? You can always override convention-over-configuration by supplying configuration! Furthermore, I seem to resemble that in the discussion about annotations you've made the same proposal as Ernst has at the beginning of this discussion - writing a custom navigation-handler which enables one to optionally not configure navigations, and not handle navigation via annotations. regards, Martin On 10/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/29/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hi! At the moment when no navigation case for an outcome is found the navigationHandler decides to stay at the same view. I think an option for web.xml would be useful to tell the navigationHandler if no navigation case for an outcome is found, but the outcome matches a viewId to navigate to this view id. This idea was mainly driven by a lot of jsf-projects where I saw for each view id: navigation-rule from-view-id*/from-view-id navigation-case from-outcomeviewId/from-outcome to-view-id/viewId.xhtml/to-view-id redirect/ /navigation-case ... which seems kind of unnecessary to me what do you think about that? I think that the developers of projects like that did not actually understand the reasoning behind the standard JSF approach to navigation. The basic theory is that an action method should return a *logical outcome* -- a string that says this is what happened, not a string that says go to this page next. That decision should be left to the architect who is gluing things all together. In particular, you should *want* to have the ability to remodel your view identifiers namespace, *without* having to go modify every single action method that returns a view id instead of a logical outcome. Consider the following use case to understand what's going on here. Lots of web sites have search text fields (like Google's search text field) that can be used to select the relevant database information. Let's assume, for the purposes of discussion, that such a text field exists to select a customer from your database of current customers. Next, let's look at this issue from the viewpoint of the developer who is writing the action method that responds to a user entering a value into the search field. If you are following good application design principles, this person will *not* know (or care) about what page should be displayed next. Instead, he or she will be focused on the fact that there are three logical outcomes that can result from a database search based on criteria specified in the search field: * No matching results were found. * Exactly one matching result was found. * More than one matching result was found. In a very simple minded application (or a RAD-developed prototype), you might be satisfied with only doing one thing in all three cases. In a user-friendly app, on the other hand, you might want to react like this: * No results -- show the search criteria page again with a message saying I'm sorry, no matches were found -- please refine your search criteria. * Exactly one result -- go directly to the next step in the user conversation, having selected a particular master record. * More than one result -- go to a page that lists the available matches and lets the user select the desired one. The key issue here ... THE DEVELOPER WRITING THE ACTION METHOD FOR THE SEARCH SHOULD NOT NEED TO KNOW WHAT HAPPENS NEXT. The important responsibility is to report this is what happened (one of the three logical outcomes). It's up to the rest of the application to react to this event. And, over the lifetime of the application, this reaction might change -- but you should *not* have to go back and do the original code over again. Given this background, I believe that the proposed feature here is *not* a good idea. It is counter to the basic philosophy behind the navigation handler architecture that the JSF spec defines. regards Ernst Craig McClanahan -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Option for NavigationHandler to support viewIds as outcome
On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig,you have been argumenting into this direction before, and I'm sorry todisagree completely. What JSF does in the standard is good forprojects where you have this necessity of different roles for page development and back-end development.It's not a matter of different roles. The design principles I advocate are the same whether there is one developer performing multiple roles, or different developers (or developer groups) performing the different roles. The architectural issues here are exactly the same in either case.Generally - for small projects, and the majority of web-projects are still small projects, the person writing the navigation-handling code,the page, and the backing-bean will be the same, so why not give themthe ability to have a convention-over-configuration approach? You can always override convention-over-configuration by supplyingconfiguration!Because that user will be crying alligator tears a year from now, or a month from now, when the person responsible for the overall organization of the webapp changes the set of view identifiers that represents the UI of an app. WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???. That is a cross-linkage between view tier and model tier that I find unacceptable in large scale apps. You have a seductive argument with respect to small scale apps. But I can tell you from 30 years of professional software development experience that managers tend to buy in to this kind of attitude at the prototype stage, when ongoing application maintenance is not a consideration. And those types of people tend to be really unhappy when the effects of this type of decision cause their maintenance budgets to skyrocket. The scale of the app does not actually matter -- the percentage of the overall budget that must be allocated to reworking previously running code is *always* a major consideration. Furthermore, I seem to resemble that in the discussion aboutannotations you've made the same proposal as Ernst has at the beginning of this discussion - writing a custom navigation-handlerwhich enables one to optionally not configure navigations, and nothandle navigation via annotations.I am *adamantly* in the no annotations for navigaiton camp ... navigation is absolutely *not* something that should be done with annotations. Doing so would have the same effect as implementing the suggested approach -- it would be requiring the person developing the server side business logic to be intimately aware of view tier considerations like what view should I show next?. Doing so makes it basically impossible to reuse business logic in scenarios like:* Migrating a non-AJAX app to be AJAX-enabled* Using the same business logic for REST-based or SOAP-based web services In short, I believe that requiring the developer of an action method to know anything about what the view tier will do next is a ***very*** bad idea.You might note that the Shale Tiger Extensions have no provision for annotation based navigation. That is a deliberate design choice, not one based on limited development time :-) regards,MartinCraig
Re: Option for NavigationHandler to support viewIds as outcome
Hi! 1) I have a managed-bean action-method which returns overview and this means, I'll go to overview.jsp As long as you placed all your jsps in the root of your webapp this works nicely, you can check if there is a navigation rule and - if not, simply add .jsp and move to this view. But if you have a directory structure (like we have) things start to be not that nicely anymore, then you have to return something like /my/view/dir/abc. You'll have to create a navigation rule with outcome /my/view/dir/abc this is not really nice. Maybe we can overcome this with an configurable NavigationNameExtractor which takes the last token of your view-Id to lookup a navigation rule. But, to say the truth, even in an small application I wont use such a NavigationHandler. I like the decoupling of navigation and destination view too, THOUGH, I dont think that this decoupling allows someone to change the navigation on the fly. In reality there is a dependency between two pages, there is a silent contract how to prepare the managed beans so that the destination page knows what to display (and I think the f:param stuff is useless here). So more often than not you'll use a updateActionListener to set stuff on the destination backing bean. And voilla, you'll have hard dependency between these two pages. Using a dialog or conversation scope here wont help much as the destination page (e.g. a search page) might participate in many different dialog or conversation scopes. At least, the replaced destination view has to use the same bean (or call it interface in this context) to determine which data to display. Said that, I wont use this new NavigationHandler, but I don't mind if we add it. Ciao, Mario
Re: Option for NavigationHandler to support viewIds as outcome
It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead of event occurred in page (logical outcome) as output. There are some bad development practices, which when a developer get used to them, it is hard to forget, I think this feature is one of them.since this bad practice(same reasons as described by Craig), makes life easier for them, when they have this feature they will get addicted to it, and they won't learn the real idea behind outcomes. I think this is like giving marijuana to JSF developers! Like the cartoon in the theserverside.com about AOP considered harmful ;-) RegardsArashOn 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig,It's all about convention over configuration, and this concept is inturn very good for maintenance. Writing unnecessary configuration codeisn't.Let's look at an automatic navigation handler in practice: 1) I have a managed-bean action-method which returns overview andthis means, I'll go to overview.jsp2) I want to change this to go to overview_2.jsp3) so I won't change anything in the managed-bean-method, but create a new navigation-rule (in your case, I'd need to change thenavigation-rule - where is the maintenance difference, I don't touchmy managed-bean?)4) If I want to go to somewhere else from any other page, I'll need to create additional navigation-rules, according to the concept of JSF.Essence is - you don't have to change anything in your managed bean,youjust add configuration rules where necessary, but keep them out where unnecessary.regards,MartinOn 10/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, you have been argumenting into this direction before, and I'm sorry to disagree completely. What JSF does in the standard is good for projects where you have this necessity of different roles for page development and back-end development. It's not a matter of different roles.The design principles I advocate are the same whether there is one developer performing multiple roles, or different developers (or developer groups) performing the different roles. The architectural issues here are exactly the same in either case. Generally - for small projects, and the majority of web-projects are still small projects, the person writing the navigation-handling code, the page, and the backing-bean will be the same, so why not give them the ability to have a convention-over-configuration approach? You can always override convention-over-configuration by supplying configuration! Because that user will be crying alligator tears a year from now, or a month from now, when the person responsible for the overall organization of the webapp changes the set of view identifiers that represents the UI of an app.WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???.That is a cross-linkage between view tier and model tier that I find unacceptable in large scale apps. You have a seductive argument with respect to small scale apps.But I can tell you from 30 years of professional software development experience that managers tend to buy in to this kind of attitude at the prototype stage, when ongoing application maintenance is not a consideration.And those types of people tend to be really unhappy when the effects of this type of decision cause their maintenance budgets to skyrocket.The scale of the app does not actually matter -- the percentage of the overall budget that must be allocated to reworking previously running code is *always* a major consideration. Furthermore, I seem to resemble that in the discussion about annotations you've made the same proposal as Ernst has at the beginning of this discussion - writing a custom navigation-handler which enables one to optionally not configure navigations, and not handle navigation via annotations. I am *adamantly* in the no annotations for navigaiton camp ... navigation is absolutely *not* something that should be done with annotations.Doing so would have the same effect as implementing the suggested approach -- it would be requiring the person developing the server side business logic to be intimately aware of view tier considerations like what view should I show next?. Doing so makes it basically impossible to reuse business logic in scenarios like: * Migrating a non-AJAX app to be AJAX-enabled * Using the same business logic for REST-based or SOAP-based web services In short, I believe that requiring the developer of an action method to know anything about what the view tier will do next is a ***very*** bad idea. You might note that the Shale Tiger Extensions have no provision for annotation based navigation.That is a deliberate design choice, not one based on limited development time :-) regards, Martin Craig--http://www.irian.at Your JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces-- Arash
Re: Option for NavigationHandler to support viewIds as outcome
Hi Mario, well, the question is if we find a good convention-over-configuration approach, and the discussion really boils down to your remark about whether you can derive the view-id from the outcome nicely. Good point. Ernst? regards, Martin On 10/30/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! 1) I have a managed-bean action-method which returns overview and this means, I'll go to overview.jsp As long as you placed all your jsps in the root of your webapp this works nicely, you can check if there is a navigation rule and - if not, simply add .jsp and move to this view. But if you have a directory structure (like we have) things start to be not that nicely anymore, then you have to return something like /my/view/dir/abc. You'll have to create a navigation rule with outcome /my/view/dir/abc this is not really nice. Maybe we can overcome this with an configurable NavigationNameExtractor which takes the last token of your view-Id to lookup a navigation rule. But, to say the truth, even in an small application I wont use such a NavigationHandler. I like the decoupling of navigation and destination view too, THOUGH, I dont think that this decoupling allows someone to change the navigation on the fly. In reality there is a dependency between two pages, there is a silent contract how to prepare the managed beans so that the destination page knows what to display (and I think the f:param stuff is useless here). So more often than not you'll use a updateActionListener to set stuff on the destination backing bean. And voilla, you'll have hard dependency between these two pages. Using a dialog or conversation scope here wont help much as the destination page (e.g. a search page) might participate in many different dialog or conversation scopes. At least, the replaced destination view has to use the same bean (or call it interface in this context) to determine which data to display. Said that, I wont use this new NavigationHandler, but I don't mind if we add it. Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Option for NavigationHandler to support viewIds as outcome
Don't forget that returning view IDs in outcomes will break tool support such as the visual page flow designer in Exadel Studio. Even without tools, I find it extremely helpful as a developer to be able to look in one place to see how the application flows. The proposed capability would make that impossible, so I agree with Craig and Arash that returning view IDs in outcomes is unsuitable for apps that will be maintained by multiple developers. Having worked as one of 30+ developers on a large application (2000 views) written in a scripting language that effectively returned view IDs in outcomes, I can testify to the horrors of code maintenance with this approach. Introducing finite state machine navigation into that code base and moving nav rules to config files has made it much easier to work on. David ChandlerJSF Consultant / Trainerlearnjsf.comOn 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead of event occurred in page (logical outcome) as output. There are some bad development practices, which when a developer get used to them, it is hard to forget, I think this feature is one of them.since this bad practice(same reasons as described by Craig), makes life easier for them, when they have this feature they will get addicted to it, and they won't learn the real idea behind outcomes. I think this is like giving marijuana to JSF developers! Like the cartoon in the theserverside.com about AOP considered harmful ;-) RegardsArashOn 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig,It's all about convention over configuration, and this concept is inturn very good for maintenance. Writing unnecessary configuration codeisn't.Let's look at an automatic navigation handler in practice: 1) I have a managed-bean action-method which returns overview andthis means, I'll go to overview.jsp2) I want to change this to go to overview_2.jsp3) so I won't change anything in the managed-bean-method, but create a new navigation-rule (in your case, I'd need to change thenavigation-rule - where is the maintenance difference, I don't touchmy managed-bean?)4) If I want to go to somewhere else from any other page, I'll need to create additional navigation-rules, according to the concept of JSF.Essence is - you don't have to change anything in your managed bean,youjust add configuration rules where necessary, but keep them out where unnecessary.regards,MartinOn 10/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, you have been argumenting into this direction before, and I'm sorry to disagree completely. What JSF does in the standard is good for projects where you have this necessity of different roles for page development and back-end development. It's not a matter of different roles.The design principles I advocate are the same whether there is one developer performing multiple roles, or different developers (or developer groups) performing the different roles. The architectural issues here are exactly the same in either case. Generally - for small projects, and the majority of web-projects are still small projects, the person writing the navigation-handling code, the page, and the backing-bean will be the same, so why not give them the ability to have a convention-over-configuration approach? You can always override convention-over-configuration by supplying configuration! Because that user will be crying alligator tears a year from now, or a month from now, when the person responsible for the overall organization of the webapp changes the set of view identifiers that represents the UI of an app.WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???.That is a cross-linkage between view tier and model tier that I find unacceptable in large scale apps. You have a seductive argument with respect to small scale apps.But I can tell you from 30 years of professional software development experience that managers tend to buy in to this kind of attitude at the prototype stage, when ongoing application maintenance is not a consideration.And those types of people tend to be really unhappy when the effects of this type of decision cause their maintenance budgets to skyrocket.The scale of the app does not actually matter -- the percentage of the overall budget that must be allocated to reworking previously running code is *always* a major consideration. Furthermore, I seem to resemble that in the discussion about annotations you've made the same proposal as Ernst has at the beginning of this discussion - writing a custom navigation-handler which enables one to optionally not configure navigations, and not handle navigation via annotations. I am *adamantly* in the no annotations for navigaiton camp ... navigation is absolutely *not* something that should be done with annotations.Doing so would have the same
Re: Option for NavigationHandler to support viewIds as outcome
Hi David, @breaking tool support: yes, that's true, and is something that might or might not be of interest to developers. @application size: For an application with 2000 views, we're definitely talking about large-size here. I'm absolutely d'accord that for a large size applications with a high number of developers assigned to them the normal navigation system should be used. Having the option of not using the default navigation system for small, simple applications is something positive, though. regards, Martin On 10/30/06, David Chandler [EMAIL PROTECTED] wrote: Don't forget that returning view IDs in outcomes will break tool support such as the visual page flow designer in Exadel Studio. Even without tools, I find it extremely helpful as a developer to be able to look in one place to see how the application flows. The proposed capability would make that impossible, so I agree with Craig and Arash that returning view IDs in outcomes is unsuitable for apps that will be maintained by multiple developers. Having worked as one of 30+ developers on a large application (2000 views) written in a scripting language that effectively returned view IDs in outcomes, I can testify to the horrors of code maintenance with this approach. Introducing finite state machine navigation into that code base and moving nav rules to config files has made it much easier to work on. David Chandler JSF Consultant / Trainer learnjsf.com On 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead of event occurred in page (logical outcome) as output. There are some bad development practices, which when a developer get used to them, it is hard to forget, I think this feature is one of them. since this bad practice(same reasons as described by Craig), makes life easier for them, when they have this feature they will get addicted to it, and they won't learn the real idea behind outcomes. I think this is like giving marijuana to JSF developers! Like the cartoon in the theserverside.com about AOP considered harmful ;-) Regards Arash On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, It's all about convention over configuration, and this concept is in turn very good for maintenance. Writing unnecessary configuration code isn't. Let's look at an automatic navigation handler in practice: 1) I have a managed-bean action-method which returns overview and this means, I'll go to overview.jsp 2) I want to change this to go to overview_2.jsp 3) so I won't change anything in the managed-bean-method, but create a new navigation-rule (in your case, I'd need to change the navigation-rule - where is the maintenance difference, I don't touch my managed-bean?) 4) If I want to go to somewhere else from any other page, I'll need to create additional navigation-rules, according to the concept of JSF. Essence is - you don't have to change anything in your managed bean, you just add configuration rules where necessary, but keep them out where unnecessary. regards, Martin On 10/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, you have been argumenting into this direction before, and I'm sorry to disagree completely. What JSF does in the standard is good for projects where you have this necessity of different roles for page development and back-end development. It's not a matter of different roles. The design principles I advocate are the same whether there is one developer performing multiple roles, or different developers (or developer groups) performing the different roles. The architectural issues here are exactly the same in either case. Generally - for small projects, and the majority of web-projects are still small projects, the person writing the navigation-handling code, the page, and the backing-bean will be the same, so why not give them the ability to have a convention-over-configuration approach? You can always override convention-over-configuration by supplying configuration! Because that user will be crying alligator tears a year from now, or a month from now, when the person responsible for the overall organization of the webapp changes the set of view identifiers that represents the UI of an app. WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???. That is a cross-linkage between view tier and model tier that I find unacceptable in large scale apps. You have a seductive argument with respect to small scale apps. But I can tell you from 30 years of professional software development experience that managers tend to buy in to this kind of attitude at the prototype stage, when ongoing application maintenance is not a consideration. And those types of
Re: Option for NavigationHandler to support viewIds as outcome
Hi Martin, may be this feature is very good for highly professional developer like you, but consider those developers new in JSF.what is the different between this and using forward and redirect methods, from developer point of view? (not considering JSF life cycle problems) (if a developer uses forward and direct, then s/he is not even forced to define a view for their page in facesconfig file! and he can use the same methods he may already know from JSP/ Servlet)I have seen lots of .net and JSP developers who were trying to use navigation rules just the way as redirects. and complaining about how hard is it in JSF to redirect into another page, (complex methods), I think this is just as Craig says because they haven't understand the deep rationality behind navigation mechanism yet, and this feature will help them never understand it! On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi David,@breaking tool support: yes, that's true, and is something that mightor might not be of interest to developers.@application size: For an application with 2000 views, we'redefinitely talking about large-size here. I'm absolutely d'accord that for a large size applications with a high number of developersassigned to them the normal navigation system should be used.Having the option of not using the default navigation system forsmall, simple applications is something positive, though. regards,MartinOn 10/30/06, David Chandler [EMAIL PROTECTED] wrote: Don't forget that returning view IDs in outcomes will break tool support such as the visual page flow designer in Exadel Studio. Even without tools, I find it extremely helpful as a developer to be able to look in one place to see how the application flows. The proposed capability would make that impossible, so I agree with Craig and Arash that returning view IDs in outcomes is unsuitable for apps that will be maintained by multiple developers. Having worked as one of 30+ developers on a large application (2000 views) written in a scripting language that effectively returned view IDs in outcomes, I can testify to the horrors of code maintenance with this approach. Introducing finite state machine navigation into that code base and moving nav rules to config files has made it much easier to work on. David Chandler JSF Consultant / Trainer learnjsf.com On 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead of event occurred in page (logical outcome) as output.There are some bad development practices, which when a developer get used to them, it is hard to forget, I think this feature is one of them. since this bad practice(same reasons as described by Craig), makes life easier for them, when they have this feature they will get addicted to it, and they won't learn the real idea behind outcomes. I think this is like giving marijuana to JSF developers! Like the cartoon in the theserverside.com about AOP considered harmful ;-) Regards Arash On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, It's all about convention over configuration, and this concept is in turn very good for maintenance. Writing unnecessary configuration code isn't. Let's look at an automatic navigation handler in practice: 1) I have a managed-bean action-method which returns overview and this means, I'll go to overview.jsp 2) I want to change this to go to overview_2.jsp 3) so I won't change anything in the managed-bean-method, but create a new navigation-rule (in your case, I'd need to change the navigation-rule - where is the maintenance difference, I don't touch my managed-bean?) 4) If I want to go to somewhere else from any other page, I'll need to create additional navigation-rules, according to the concept of JSF. Essence is - you don't have to change anything in your managed bean, youjust add configuration rules where necessary, but keep them out where unnecessary. regards, Martin On 10/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, you have been argumenting into this direction before, and I'm sorry to disagree completely. What JSF does in the standard is good for projects where you have this necessity of different roles for page development and back-end development. It's not a matter of different roles.The design principles I advocate arethe same whether there is one developer performing multiple roles, ordifferent developers (or developer groups) performing the different roles. The architectural issues here are exactly the same in either case.Generally - for small projects, and the majority of web-projects are still small projects, the person writing the navigation-handling code, the page, and the backing-bean will be the same, so why not
Re: Option for NavigationHandler to support viewIds as outcome
Hi Arash, I don't think we're in the JSF space to force developers to do something in a certain way. The navigation system of JSF is good, it's been devised with decoupling in mind, and you might want or not want that for your application - I don't think that the rationale behind this is hard to grasp for anyone. So your sentence about the deep rationality behind the navigation mechanism is a bit overblown... Especially, as with what Ernst suggested, you can still configure - you just don't have to! There is a host of web-frameworks which don't build on this decoupling out of the box - so why not giving the developer the option to do things in the way they're used to? Mind it, I'm not one of the guys who hate configuration files, and I don't have anything against faces-config.xml. There are people out there who want to reduce it to a bare minimum, though, and I don't see why one shouldn't. Enough said, there are pro's and con's, and I do believe that an option won't hurt anyone, if it's nicely implemented. regards, Martin On 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi Martin, may be this feature is very good for highly professional developer like you, but consider those developers new in JSF. what is the different between this and using forward and redirect methods, from developer point of view? (not considering JSF life cycle problems) (if a developer uses forward and direct, then s/he is not even forced to define a view for their page in facesconfig file! and he can use the same methods he may already know from JSP/ Servlet) I have seen lots of .net and JSP developers who were trying to use navigation rules just the way as redirects. and complaining about how hard is it in JSF to redirect into another page, (complex methods), I think this is just as Craig says because they haven't understand the deep rationality behind navigation mechanism yet, and this feature will help them never understand it! On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi David, @breaking tool support: yes, that's true, and is something that might or might not be of interest to developers. @application size: For an application with 2000 views, we're definitely talking about large-size here. I'm absolutely d'accord that for a large size applications with a high number of developers assigned to them the normal navigation system should be used. Having the option of not using the default navigation system for small, simple applications is something positive, though. regards, Martin On 10/30/06, David Chandler [EMAIL PROTECTED] wrote: Don't forget that returning view IDs in outcomes will break tool support such as the visual page flow designer in Exadel Studio. Even without tools, I find it extremely helpful as a developer to be able to look in one place to see how the application flows. The proposed capability would make that impossible, so I agree with Craig and Arash that returning view IDs in outcomes is unsuitable for apps that will be maintained by multiple developers. Having worked as one of 30+ developers on a large application (2000 views) written in a scripting language that effectively returned view IDs in outcomes, I can testify to the horrors of code maintenance with this approach. Introducing finite state machine navigation into that code base and moving nav rules to config files has made it much easier to work on. David Chandler JSF Consultant / Trainer learnjsf.com On 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead of event occurred in page (logical outcome) as output. There are some bad development practices, which when a developer get used to them, it is hard to forget, I think this feature is one of them. since this bad practice(same reasons as described by Craig), makes life easier for them, when they have this feature they will get addicted to it, and they won't learn the real idea behind outcomes. I think this is like giving marijuana to JSF developers! Like the cartoon in the theserverside.com about AOP considered harmful ;-) Regards Arash On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, It's all about convention over configuration, and this concept is in turn very good for maintenance. Writing unnecessary configuration code isn't. Let's look at an automatic navigation handler in practice: 1) I have a managed-bean action-method which returns overview and this means, I'll go to overview.jsp 2) I want to change this to go to overview_2.jsp 3) so I won't change anything in the managed-bean-method, but create a new navigation-rule (in your case, I'd need to change the navigation-rule - where is the maintenance difference, I don't touch my managed-bean?) 4) If I want to
Re: Option for NavigationHandler to support viewIds as outcome
Hi Martin,First thanks for taking time and answering me.Believe me or not, the concept is hard to grasp for lots of developers, at least for people in my country who are not as wise and intelligent as people in Germany and Austria, lots of developers are not Computer Science PHD and most of them are not even college educated!I remember 10 years ago, when we were developing codes in C++, most of our time was spend on finding memory problems caused by illegal pointers created by freeing an object in wrong places. Now with garbage collection in java it is years that I haven't seen the problem, although average knowledge of developers is much lower now because of high demand in IT industry.May be this phrase is wrong, but it think a good development framework (especially those who are designed for ease of use) should not let developers make mistakes.I remember when I was in guidance primary school, our Pascal and C programming teacher decided not to teach us about Labels, because he knew that some of us had some experience in GW-Basic programming and we can't get ride of GOTO, and we can't ever learn structured programming, now I think the same case is about this NavigationHandler mechanism, it is like goto in structured languages.RegardsArash On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Arash,I don't think we're in the JSF space to force developers to dosomething in a certain way. The navigation system of JSF is good, it'sbeen devised with decoupling in mind, and you might want or not want that for your application - I don't think that the rationale behindthis is hard to grasp for anyone. So your sentence about the deeprationality behind the navigation mechanism is a bit overblown... Especially, as with what Ernst suggested, you can still configure -you just don't have to!There is a host of web-frameworks which don't build on this decouplingout of the box - so why not giving the developer the option to do things in the way they're used to? Mind it, I'm not one of the guyswho hate configuration files, and I don't have anything againstfaces-config.xml. There are people out there who want to reduce it toa bare minimum, though, and I don't see why one shouldn't. Enough said, there are pro's and con's, and I do believe that anoption won't hurt anyone, if it's nicely implemented.regards,MartinOn 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi Martin, may be this feature is very good for highly professional developer like you, but consider those developers new in JSF. what is the different between this and using forward and redirect methods, from developer point of view? (not considering JSF life cycle problems) (if a developer uses forward and direct, then s/he is not even forced to define a view for their page in facesconfig file! and he can use the same methods he may already know from JSP/ Servlet) I have seen lots of .net and JSP developers who were trying to use navigation rules just the way as redirects. and complaining about how hard is it in JSF to redirect into another page, (complex methods), I think this is just as Craig says because they haven't understand the deep rationality behind navigation mechanism yet, and this feature will help them never understand it! On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi David, @breaking tool support: yes, that's true, and is something that might or might not be of interest to developers. @application size: For an application with 2000 views, we're definitely talking about large-size here. I'm absolutely d'accord that for a large size applications with a high number of developers assigned to them the normal navigation system should be used. Having the option of not using the default navigation system for small, simple applications is something positive, though. regards, Martin On 10/30/06, David Chandler [EMAIL PROTECTED] wrote: Don't forget that returning view IDs in outcomes will break tool support such as the visual page flow designer in Exadel Studio. Even without tools, I find it extremely helpful as a developer to be able to look in one place to see how the application flows. The proposed capability would make that impossible, so I agree with Craig and Arash that returning view IDs in outcomes is unsuitable for apps that will be maintained by multiple developers. Having worked as one of 30+ developers on a large application (2000 views) written in a scripting language that effectively returned view IDs in outcomes, I can testify to the horrors of code maintenance with this approach. Introducing finite state machine navigation into that code base and moving nav rules to config files has made it much easier to work on. David Chandler JSF Consultant / Trainer learnjsf.com On 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead
Re: Option for NavigationHandler to support viewIds as outcome
On 10/30/06, Mario Ivankovits [EMAIL PROTECTED] wrote: In reality there is a dependency between two pages, there is a silentcontract how to prepare the managed beans so that the destination pageknows what to display (and I think the f:param stuff is useless here). So more often than not you'll use a updateActionListener to set stuff onthe destination backing bean. And voilla, you'll have hard dependencybetween these two pages.This is an important point, no matter how you architect your navigation. shameless-plugThat is why Shale's view controller has a prerender() method ... you are encouraged to use that method in the destination page to pull data that this page needs out of the model, rather than having the origin page push data into the destination page (or some request scoped objects whose names are known to both). That way, coupling is minimized to something like passing primary keys -- and I like the convention of always passing, say, a customerId, in the same place throughout the application (independent of particular pages), to minimize direct coupling between any two particular pages. This approach also makes it *much* easier for your application to support bookmarkable GET URLs that pass primary keys with request parameters./shameless-plugCraig
Option for NavigationHandler to support viewIds as outcome
Hi! At the moment when no navigation case for an outcome is found the navigationHandler decides to stay at the same view. I think an option for web.xml would be useful to tell the navigationHandler if no navigation case for an outcome is found, but the outcome matches a viewId to navigate to this view id. This idea was mainly driven by a lot of jsf-projects where I saw for each view id: navigation-rule from-view-id*/from-view-id navigation-case from-outcomeviewId/from-outcome to-view-id/viewId.xhtml/to-view-id redirect/ /navigation-case ... which seems kind of unnecessary to me what do you think about that? regards Ernst
Re: Option for NavigationHandler to support viewIds as outcome
I think this is a bad idea for following reasons:1) it is against the spec behaviour2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes 3) this make confusion between page names and outcomes (navigation events)4) I think outcomes and names of JSF pages should stay separate.JSF navigation is like an finite state machine (FSM) or finite state automaton, states are pages and outcomes are input to the automaton, this keeps modeling UI very simple. and also it makes it possible for formal verification of JSF application, with available tools.RegardsArash RajaeeyanOn 10/30/06, Ernst Fastl [EMAIL PROTECTED] wrote:Hi! At the moment when no navigation case for an outcome is foundthe navigationHandler decides to stay at the same view. I thinkan option for web.xml would be useful to tell the navigationHandlerif no navigation case for an outcome is found, but the outcome matches a viewId to navigate to this view id.This idea was mainly driven by a lot of jsf-projects where I saw for eachview id:navigation-rulefrom-view-id*/from-view-id navigation-casefrom-outcomeviewId/from-outcometo-view-id/viewId.xhtml/to-view-idredirect//navigation-case ...which seems kind of unnecessary to mewhat do you think about that?regardsErnst
Re: Option for NavigationHandler to support viewIds as outcome
1) it is against the spec behaviour Of course you are absolutely right with this therefore I'd make it an optional feature, being able to turn it on with a configuration parameters 2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes Sorry don't get your point here, if an action returns a misspelled outcome or a misspelled viewId you would not want to navigate in both cases right? 3) this make confusion between page names and outcomes (navigation events) Confusion is exactly the point, what I get told as the main reason not to choose JSF by many users considering it is: It is to complex for me I have to write all those xml-files to get just Hello world running That would be a way for them with one configuration file less. 4) I think outcomes and names of JSF pages should stay separate. JSF navigation is like an finite state machine (FSM) or finite state automaton, states are pages and outcomes are input to the automaton, this keeps modeling UI very simple. and also it makes it possible for formal verification of JSF application, with available tools. Good point. But again, no one would be forced to use the feature, I'd say it's for starters and lazy programmers, the others can leave it turned off. All together, I see your points, but I don't understand what harm could be caused by an optional feature? On 10/30/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hi! At the moment when no navigation case for an outcome is found the navigationHandler decides to stay at the same view. I think an option for web.xml would be useful to tell the navigationHandler if no navigation case for an outcome is found, but the outcome matches a viewId to navigate to this view id. This idea was mainly driven by a lot of jsf-projects where I saw for each view id: navigation-rule from-view-id*/from-view-id navigation-case from-outcomeviewId/from-outcome to-view-id/viewId.xhtml/to-view-id redirect/ /navigation-case ... which seems kind of unnecessary to me what do you think about that? regards Ernst
Re: Option for NavigationHandler to support viewIds as outcome
2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes Sorry don't get your point here, if an action returns a misspelled outcome or a misspelled viewId you would not want to navigate in both cases right? I think he means the 404 error, ... However, I kinda like stuff like that, but not configurable! We had had enough fun with bogus features like dummyForm. We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if sb. really really want that, use that particular NH. just my $0.02 -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Option for NavigationHandler to support viewIds as outcome
You're right, an alternate NavigationHandler shipped with MyFaces is probably the better choice let's go with that approach. thanks for your ideas On 10/29/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: 2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes Sorry don't get your point here, if an action returns a misspelled outcome or a misspelled viewId you would not want to navigate in both cases right? I think he means the 404 error, ... However, I kinda like stuff like that, but not configurable! We had had enough fun with bogus features like dummyForm. We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if sb. really really want that, use that particular NH. just my $0.02 -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Option for NavigationHandler to support viewIds as outcome
Ernst, you also wanna check some of the *extensions* in the MyFAcesNH_Impl for accessing navigation cases. It is important in security cases to *check* navigation cases ... so your impl could benefit from that ! On 10/29/06, Ernst Fastl [EMAIL PROTECTED] wrote: You're right, an alternate NavigationHandler shipped with MyFaces is probably the better choice let's go with that approach. thanks for your ideas On 10/29/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: 2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes Sorry don't get your point here, if an action returns a misspelled outcome or a misspelled viewId you would not want to navigate in both cases right? I think he means the 404 error, ... However, I kinda like stuff like that, but not configurable! We had had enough fun with bogus features like dummyForm. We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if sb. really really want that, use that particular NH. just my $0.02 -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
