Have you seen JSF lately? (Part 3)
While JSPs are widely used and understood, their use in JSF has always been controversial. But love it or hate it, it's always been true that JSPs never quite fit in with JSF, and there were always some rough edges around where the two technologies fit together. All that's changed with JSF 2, since it uses the widely loved Facelets technology as it's primary page language. In fact, while you can still use JavaServer Pages for all of the pages written for JSF 1.2, to get the full use of JSF 2 features, you'll need to author pages in Facelets.
There's plenty of writeups for Facelets on the web already, as well as books or chapters of books on the topic, so I won't make this into a little miniature tutorial on Facelets, but it's probably worth hitting this one high point:
Templating is easy with Facelets
To create a template page, you code up a standard xhtml page with a html element that looks like this:
Then, use that ui namespace to define regions in the page, using the
<title><ui:insert name="title">Default title</ui:insert></title>
If we put that into a file called template.xhtml, then we can call it with the following code, using the
<ui:define name="title">I like templates</ui:define>
There are lots of subtleties here that I'm not covering, but you get the idea. Combine this with the ease of making new components via the composite component feature I mentioned earlier, and you can see that this is a pretty powerful way to handle serving web pages from composite parts.
One more note on Facelets: One book that comes highly recommended to me (though I've not read it myself), is Bruno Aranda's book. I'm told it covers the technology throughly.
So, far in this series I've covered Ajax support, component creation, templating with Facelets, and annotations. But the one question I always get is "what about Bookmarkable links?". Usually, the person asking is condensing a few issues into that one question, and it all comes down to GET vs POST.
After configuration files, perhaps the most common complaint about JSF is that everything is done via POST. This complaint is usually driven by a few points, some of which overlap - POST requests don't get cached (since they don't offer what's called idempotency, or the ability to get the same result from two identical requests). Also, POST requests cannot be bookmarked, and they often cause the browser to ask you awkward questions when you use the "back" button.
Now, JSF uses POST for a few reasons. For one, the limit on the size of GET requests (more than 2000 characters may fail in some situations - and those situations are mostly beyond your control). POST (with the generated view id's embedded by JSF) offers some minor security benefits as well, since it's more laborious to spoof requests (though a determined person can always get through). There's also the problem that the framework doesn't know when you intend a screen to be idempotent (i.e., repeatable) and when you don't. But, good news:
There's good support for GET in JSF 2
Ryan Lubke just published a really good description of how this works. I urge you to read through it to see the details, but the upshot of it is two new tags:
So, have you seen JSF lately?
Hopefully you've stayed with me this far, and you've seen that there's good reason to be excited about the new JSF 2. It'll be here sooner than you think, and there's no reason to not give it a try. You can get the latest beta from the Project Mojarra website, in the downloads section.