Posted by driscoll on May 29, 2009 at 3:32 PM PDT
Mojarra just went Beta, and the JSF spec just passed the JCP vote. If you haven't looked at JSF in a while, it's time to take another look.
Continuing our look at the improvements of the new JSF spec - see previous blogs here and here.
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.
If we put that into a file called template.xhtml, then we can call it with the following code, using the tag.
<ui:composition template="template.xhtml"> <ui:define name="title">I like templates</ui:define> </ui:composition>
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:
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.