Skip to main content

Have you seen JSF lately? (Part 1)

Posted by driscoll on May 27, 2009 at 6:40 PM PDT

One of the most persistent annoyances in working on JSF is the pervasiveness of old information, usually from years ago, and often now inaccurate. Google ranks the JSF 1.1 tutorial over the JSF 1.2 tutorial... One Tweet I recently read referred to a Joe Ottinger blog from 2007 - over 2 years ago. Yet it was referenced as new information. Still another blog I recently read contained information and quotes from 2004. John Kerry was still a candidate for President (Heck, Howard Dean was still a candidate for President), folks still thought housing was a great investment, and Brittany was ripping up the charts with her new hit "Toxic". Ronald Reagan and Yasser Arafat were both still alive. That's a pretty long time ago.

So, to those people (and to the rest of you, as well), I'd simply like to ask: have you seen JSF lately?

The JSF 2.0 spec is going to final ballot as I write this, and we've been working on the implementation of that spec for over a year now. That implementation is now beta, and will be out as FCS before the end of the year. It's time to take a new look. If you don't, you're cheating yourself.

So, if you haven't looked at JSF lately, I'd like to use this series of blogs (three, I think) to look at things that folks used to complain about WRT JSF, and what the new JSF 2 standard does that addresses those complaints.

Here's the first one:

Configuration files.

I admit it, I never liked the idea of separating out configuration from implementation - either in the main line of J2EE, or in JSF. Sure, it's useful in some cases, but certainly not the common case. With the new Annotation support, the need for configuration files (mostly) disappears.

The new JSF specification practices the "DRY" principle (Don't Repeat Yourself). One application of this is for Managed Beans. If you have to take the time to write a Managed Bean java class, why should you have to take any additional action to tell the system, “hey, see this Java class here? This is a managed bean.”

So, instead of creating a configuration file to declare your managed bean, you can instead just use the @ManagedBean annotation at the top, and it's added to your application. Want it scoped to a session? Add @SessionScoped. (You can see the JavaDocs for these annotations on the Project Mojarra site, or as part of the spec download). Similarly, to navigate from one page to another, it used to be necessary to add a bunch of wordy and cryptic "navigation-rule" elements. No more. Now, a reference of action="page2" inside a button or a link will just take you to page2.xhtml, no muss, no fuss, no bother.

That's not to say that configuration files have gone away - you can still use them, such as for a large site with a complicated navigation map. Some people would prefer that the navigation be all in one spot for that use case. There's also some things you still must use configuration files for, such as taking a Bean class and creating two different named managed Beans from that class - adding the annotations to do that would have just made the wording awkward to handle such a corner case.

But for most applications, we think that you won't need very much in a configuration file, if anything at all.

And since that didn't take long, here's a second, about Ajax support:

One place where a component based architecture like JSF can really come in handy is when you want to abstract away some really tricky bits of code, and hide them from the rest of the page's architecture. If there was ever a great use case for that idea, it's Ajax.

Ajax support is fully integrated into JSF 2

I've already written quite a few blogs on Ajax support, as well as integrating it into the new component features, so I won't go into this aspect of JSF 2 too much. But just to hit the highlights, you can now Ajax enable a standard component simply by wrapping it in an tag. All the variables in the page can thus be modified via this new Ajax tag, just as if you had done a full page submit.

For example: say you have a form that looks like this:

<h:outputText id="out" value="#{}"/>
<h:commandButton id="button" value="Press me"
<f:ajax execute="@this" render="out"/>

Now, when you press the button, an ajax request is sent which executes the doSomething method on the server, and changes the value of the "out" text to match what's on the server. All without a single line of JavaScript written by the user.

More in the next installment.

Related Topics >>