Speed up development, reduce bandwidth, enhance user experience. This article gives a brief overview of JSF navigation, some of the problems, and potentially how to solve them by enabling bookmarkable, pretty URLs. Put simply… in my view, out of the box, JSF is a web framework designed for web-applications, not designed for web-sites. PrettyFaces addresses most of these issues.

Target audience for this article:

1. The reader is familiar with JSF navigation.
2. The reader is attempting to create a JSF app with bookmarkable “pretty” URLs. E.g.: …/mysite/archives/2008/11/11/
3. The reader is familiar with HTTP request/response at a basic level.

The difference between a web-application / web-site

When I think of a web-site, I think of a group of pages having:

• Multiple points of entry
• Navigation via <a href> or <form> HTML elements.
• Mostly stateless; the application may care who you are, but usually does not care where you came from, or where you have been.

When I think of a web-application, I think of a group of pages having:

• One or only a few points of entry (login page, etc. No direct links.)
• Navigation via page-flows.
• Mostly stateful; the application cares who you are and where you have been.

So when I say that JSF was designed for applications, I mean that without extension, normal, mostly-stateless web-behavior can be more difficult to implement than stateful web-behavior. The problem here, however, is that if a web-site is “stateless,” JSF forces you to behave in a stateful way. Here’s why.

<h:form> – the root of the problem

Forms in JSF are rendered by the <h:form> component, and each form must post back to the viewId from which it was rendered (aptly named a postback.) Once the form has been submitted back to the requested URL, JSF will determine which page the user should see next, and either render that view, or redirect the client’s browser to a new URL.

• An example view Id: …/mysite/faces/articles/viewArchives.jsf

There are a few existing frameworks to get our bookmarkable URLs, but all suffer from a troubling set of problems:

1. Restfaces – solely intended to manage Pretty/Bookmarkable JSF navigation
2. PrettyUrlPhaseListener – a small utility provided in the sandbox for Mojarra Scales
3. UrlRewriteFilterCannot process unordered query-parameters reliably: ‘?foo=1&bar=2′ vs. ‘?bar=2&foo=1′

And most serious solutions have heavyweight configurations with a steep learning-curve.

Problems:

• When you submit a form, the JSF view ID is shown in the URL bar instead of the Pretty URL. This occurs for validation and also standard navigation without server-side redirects.
• When form validation occurs, the view ID is again shown in the URL bar. This causes contextual information contained in the URL to be lost. The information must instead be rendered as hidden form input fields, and re-submitted with the form. The developer must now manually process these values and reload them in every action method. The other option is to make your managed beans “session” scoped, which causes other problems.
• Mulitple requests to preserve the URL mean wasted bandwidth, longer client wait times, and higher CPU utilization.

A proposed solution

It’s simple, really… Modify JSF to submit the form to the pretty URL (/mapped/page) instead of the view Id (/faces/page.jsf)

• An example PrettyFaces URL: …/mysite/archives/2008/11/11/

(Read through the presentation to see why PrettyFaces, a new OpenSource library by OcpSoft, may be a good alternative)

—-

How to make JSF bookmarkable like a web-site, not behave like an application.

—-

Conclusion:

When the form is submitted to the pretty URL instead of the JSF view ID, you gain performance, save resources, and make life for the developer easier; parameter values are not lost, and do not need to be coded into the form or session scoped beans.

Try PrettyFaces, an opensource solution by OcpSoft. (Check the project homepage, here).