So, a little while ago I was attempting to use JSF’s Facelets <ui:repeat> tag, as a replacement for <h:dataTable>, but difficulty came when I needed to process actions on individual records of each row. <ui:repeat> allows iteration over a List of Array[] of items, but it does not provide a method of discovering the “selected” or “actioned” row; there’s no way to discover the row the user is interacting with. Or is there?

So, one of the best ways I know of to tell a user that they should be waiting for something to finish, is by setting the cursor to ‘wait’. It’s how desktop applications do it. It’s how the operating system does it… it’s how ajax should probably do it (if you want to solve the user wait interaction globally.) With JSF2, it’s easy to accomplish!

If you are manipulating any FacesContext when doing any kind of Sevlet Forwards – such as from a filter – you MUST release() any FacesContext you’ve created. The consequences of forgetting this are potentially dire.

So you’ve got Spring Security up and running. Great! Now you’ve got a login page, and you just added a form on the global page menu to allow users to Login from any public page. There’s just one problem. When they log-in from a public page, they’re redirected to the default-login-url! Your users will have to re-navigate to the page they were already viewing when they logged in, or maybe they’ll just use the much dreaded “Back” button. That’s not a good interaction, but we have a solution.

Several things that make life painful with Facelets are fixed with JSF2 & EzComp. Take a look at some of the nicer things to come:

A correction has been made to the post: http://ocpsoft.com/java/acegi-spring-security-jsf-login-page/, fixing an issue where FacesMessages were not being displayed on failed authentications.

Add a comment with your experience or “gotcha!”

Java Server Faces is currently full of relatively undocumented features and behavior. As part of the JSF2 release, OcpSoft is working with a few folks at Seam/Redhat to try to address these issues and provide better documentation.

“The community was speaking, but until recently, nobody was listening.”

A lot has changed since May 15, 2001, when the first ballot review of the JSF 1.0 framework was just beginning. To this day, Sun’s flagship web-application framwork has been an uncompromising box of tricks and gotchas, with little community adoption. This has been mostly due to its relatively developer-unfriendly nature; however, the second phase is coming, and with JSF2.0 peeking out from the edge of its nest, a new life is beginning to show.

It didn’t make it…

Well folks, for those of you who were hoping JSF 2.0 would contain the URL rewriting tools that many had asked for, unfortunately it looks like it’s not going to make it into the official spec. Bookmarking a page, or pages in JSF has been a heavily requested feature, but according to this discussion, is currently out of scope.

But that’s ok…

The PrettyFaces JSF Bookmark extension has been updated for JSF 2.0, and is ready for public preview (download below).

The Problem:

So you need a way to instantiate the 2.0 FacesContext in a Filter, but when you use the same method that you have in the past, you get NullPointerExceptions all over the place when attempting to access any values through El. The ScopedAttributeElResolver bombs when attempting to set values or access methods in backing beans.) It’s not too hard to get this working again. In fact, this is how our own URL-rewrite filter for JSF handles things behind the scenes.