Make JSF intuitive, with bookmarkable and pretty URLs
What makes Pretty URLs in JSF so hard, and so slow?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:
- The reader is familiar with JSF navigation.
- The reader is attempting to create a JSF app with bookmarkable “pretty” URLs. E.g.: …/mysite/archives/2008/11/11/
- 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.
<h:form> – the root of the problemForms 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
- Restfaces – solely intended to manage Pretty/Bookmarkable JSF navigation
- PrettyUrlPhaseListener – a small utility provided in the sandbox for Mojarra Scales
- UrlRewriteFilterCannot process unordered query-parameters reliably: ‘?foo=1&bar=2’ vs. ‘?bar=2&foo=1’
- 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 solutionIt’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/
How to make JSF bookmarkable like a web-site, not behave like an application.