Skip to main content

JSFOne idea: infer to-view-id

Posted by edburns on September 23, 2008 at 2:39 PM PDT

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:


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 style="text-decoration: line-through;">blame thank.

Technorati Tags:

Related Topics >>


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;

+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.

+1, although this forces your actions to be aware of navigation. I don't know if i'm happy with that.

+1. JBoss Seam already implements something very similar

+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.

+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...

Ed, Slightly off topic, but something I've been doing for the past few years (eg. I can confirm it's useful in real world systems) is to support wildcards in the 'to-view-id'. If a wildcard is present, the outcome is merged into the wildcard. So you can do... <navigation-case> <from-action>#{provider.addProviderRep}</from-action> <to-view-id>/staff/providerRep.jsf?providerRep.current.provider={0}

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.

+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.

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.

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.

+1! We have been doing something like this in MAKEFaces ( 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.

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! :)