At JSFOne, someone suggested modifying the navigation rule system such that if the to-view-id is absent from a navigation-case, the to-view-id value be inferred from the outcome.

This would mean the following is valid:

<navigation-rule> 
    <from-view-id>/pages/inputname.jsp</from-view-id> 
    <navigation-case> 
      <from-outcome>sayHello</from-outcome> 
    </navigation-case> 
    <navigation-case> 
      <from-outcome>sayGoodbye</from-outcome> 
    </navigation-case> 
</navigation-rule>  

If the outcome is sayHello, the to-view-id is sayHello.xhtml.

If the outcome is sayGoodbye, the to-view-id is sayGoodbye.xhtml.

Naturally, I think if we do this we can dispense with the navigation-rules alltogether and say that if there is no navigation-rule for the page you're on, then just infer the to-view-id by takeing the outcome, tacking .xhtml onto it, and going there.

Is this a good idea?

If you're reading this blog and you're the person who gave me this idea, thanks and please follow up so we know who to blame thank.

Technorati Tags: edburns

13 Comments

  • 392 Guest Newbie
    FWIW, Mojarra Scales has this capability (iirc).  It's not a (well?) documented feature, nor one I've dealt with much of late.  That implementation is also not unique, as there are others in various projects.  I give this an enthusiastic thumbs up! :) //
    • 392 Guest Newbie
      +1! We have been doing something like this in MAKEFaces (https://makefaces.dev.java.net): when no navigation rules have ben declared, or the result of an action does not match any navigation case we just append .xhtml to that view. //
      • 392 Guest Newbie
        This may be a blatantly obvious point, but I'll ask about it just in case: I assume you don't literally mean add .xhtml, but whatever is defined under javax.faces.DEFAULT_SUFFIX, right? In that case, I'm all for it. //
        • 392 Guest Newbie
          This seems like a perfect solution for a third-party product.  The standard ought to worry about keeping itself flexible enough for third party solutions like this to thrive. //
          • 392 Guest Newbie
            +1, I often see developers writing outcomes like "toSomePage", that lead to "somePage.xhtml". This sounds like a nice way to reduce that (unnecessary) code. //
            • 392 Guest Newbie
              Enthusiastic +1 for that idea. That would put it more in line with frameworks like Spring MVC which are competitive because they remove this sort of minutae. //
              • 392 Guest Newbie
              • 392 Guest Newbie
                +1, this is something I've wanted since I started using JSF a couple of years ago.  I guess I just assumed that you'd have had hundreds of people suggesting this to you already... //
                • 392 Guest Newbie
                  +1 for me as well. As mentionend, the to-view-id will (in most cases) be the same as the outcome plus the extension. I actually remember being at the session at JSFOne where the suggestion was brought up. Can't remember who it was though. //
                  • 392 Guest Newbie
                    +1. JBoss Seam already implements something very similar //
                    • 392 Guest Newbie
                      +1, although this forces your actions to be aware of navigation. I don't know if i'm happy with that. //
                      • 392 Guest Newbie
                        +1, in our internal JSF framework, we do something alike. We use the return value of action method to infer the path of the page.  Even though this makes the navigation less flexible, but the current navigation configuration is just a little painful. A simple navigation involves so many lines of XML, which isn't quite worth it. //
                        • 392 Guest Newbie
                          Yes, I've added an implementation of this idea in the past for a project I've worked. Following is my proof of concept implementation; http://cagataycivici.wordpress.com/2008/11/13/xml-less-jsf-navigations/ //