JSF implicit vs. explicit navigation

Question

I was considering using explicit page navigation rules in my web app when I came accross this SO question/answer, with the following excerpted from it:

...navigation rules are obsolete since JSF 2.0 thanks to the new "implicit navigation" feature.

However, I've gone through most of the CoreServlets JSF 2.0 tutorial, and it has a section devoted to explicit page navigation, and it talks favorably about it. Either this goes against the above recommedation, or am I misinterpreting something.

I don't want to create a new web app in an obsolete manner. Can anyone shed any light?

Armenian

Answer 1

This is somewhat subjective, but ala, it boils down to the following:

1. Navigation rules in XML are a maintenance hell.

2. Using navigation rules suggests that the web application in question suffers from the "one URL behind" problem which causes bad user experience (pages are not bookmarkable).

3. Using navigation rules suggests that the web application in question is using POST for page-to-page navigation which causes not only bad user experience (pages are not bookmarkable), but also bad SEO (bots don't index POST, hence POST-navigated pages are unreachable for public search engines).

See also:

• How to navigate in JSF? How to make URL reflect current page (and not previous one)
• Bookmarkability via View Parameters feature
• When should I use h:outputLink instead of h:commandLink?
• Communication in JSF 2.0 - Implicit navigation

Heads

Answer 2

From a purely technical point of view navigation rules are not obsolete, as-in that neither the spec nor any API marks them as being obsolete, deprecated or a candidate to be pruned.

In fact, they have gotten somewhat of a revival in JSF 2.2 with the Faces Flow feature for reusable modules.

That said in practice and surely when the Faces Flow feature is not used I've never seen much use for navigation rules in XML. They would theoretically make maintenance easier (IIRC that's one of their original design goals), but in practice as BalusC mentions it only causes maintenance hell.

But as BalusC also mentioned, it IS subjective. Some people still actually like to primarily define managed beans, injections (wiring), entity mappings and what have you in XML instead of with annotations (and with XML only as possible override or for global things).

In my opinion navigation rules mainly reflect the initial attempt of JSF to abstract too much from HTTP and present a higher level desktop-like programming model. In that model redirecting to a URL with query parameters and all did not really had a place. For some time now (starting with JSF 2.0) JSF has moved into a more middle ground model, where plain GET requests and PRG (Post-Redirect-GET) is much more embraced. Following this new model you could indeed say that navigation rules have no place, i.e. are effectively obsolete.

Hydrogenate

Answer 3

You can use either.

Explicit means in xml code, which leads to:

1. More overhead, specially if conditions are complex (you must match the result from the action method with the expected values).

   1b) If there are typos, implicit navigation will probably lead to a 404. Explicit will lead to the wrong page.

2. You can use tools to draw the rules in a GUI that later generate the faces-config.xml.

3. At a latter time, changing the rules means changing the XML (you do not need to recompile). If you change your URLs/JSF page names, you won't need to recompile.

I would say using one or the other is a matter of preference, I am quite happy using implicit navigation.

Lareine

Any insight regarding the comment about being obsolete? The comment was made by BalusC, and due to his massive body of work here on SO, I tend to take his answers seriously. – Armenian

>You can use tools to draw the rules in a GUI while this seems cool at first and gives you some insight into the flow of your app, these diagrams tend to become enormously cluttered when your app grows beyond a few pages. – Hydrogenate