Your first Java Server Faces application - a slight variation on hello world for JSF

This message was edited 1 time. Last update was at 12/23/2005 11:08:51

This article is a simple "Hello World" type of application using Java Server Faces or JSF. This is a fairly new Java Enterprise Edition technology that aims to standardize and simplify HTML form parsing and web flow mechanisms. In that respect it has some strong conceptual similarities with Struts. However, in my mind JSF takes Struts further into a true MVC model. As Craig McClanahan, the original creator of Struts was part of the Java Server Faces JSR he has helped include some of the great ideas of Struts into JSF.

So, onto the code!

On the presentation side JSF is basically a few JSP tag libraries that help with presentation and web flow. Our sample application is going to allow someone to input their name and have JSF say hello to them (yeah, it'll be a real exciting application

). So lets start with the page where users are asked for their name:

This is the initial JSP that will be presented to a user. It asks for a user name and contains a submit button. One of the cool things is that this example includes some simple validation. No extra code needs to be written to have the page validate that the input name has to be between 2 and 10 characters.

The first two lines of the file simply define the JSF tag libraries. The prefix is not required to be as shown but these are the ones commonly used so I'll stick with that.

Next the line:
loads a message bundle for our JSP. JSF, like Struts and well written JSP's strongly encourages you to use resource bundles for all the text and this example uses that.

After some normal HTML preamble you can see the first time we use the JSF tag lib with the h:outputText tag. This tag does exactly what it says - it outputs text. The syntax "#{ ... }" is modeled on the JSP expression language. It looks almost the same but for JSF it has the "#" instead of the "$".

Next, since ultimately this page is posted back to itself in a failure case we include any error messages that have occured during processing. This is very similar to the Struts <html:errors> tag.

The form is defined next. None of this is too difficult to figure out what is going on. As I mentioned one of the cool things is that we're building validation into this form. As you can see:

we tell JSF that the input text is required and that it must be between 2 and 10 characters. This is all done with just the declaration - no extra code must be written.

Lastly we have a commandButton (a button to submit the form) that has the action of "greeting". Again, like Struts this is an externalized reference to where we want the page to go next.

This message was edited 1 time. Last update was at 01/27/2006 15:22:17

Just a couple of quick suggestions/comments/questions

Since my new primary function at work is to change a line of code every 2-3 days or tell a testing team why their test case is invalid i figured i should use my copious amounts of down time and learn something. First up, you guessed it JSF.

I checked out this tutorial obviously, but not coming from a struts or something similar background i was quickly lost.

I looked around and found a lot of tutorials that were IDE specific, but eventually found this link
After screwing around with weblogic and directory structures (and learning more about weblogic and directory structures) for a while I got it working. Now I'm left with trying to figure out what I actually just did.

So my recommendation, when you get around to it obviously

, would to cover setting up JSF. What jars do you need, what config files, changes the web.xml file, etc.
Perhaps if i get ambitious I’ll write something up (if you don't mind)

Another thing was when i was following that other link i got this error:

java.lang.NullPointerException
at com.sun.faces.taglib.jsf_core.LoadBundleTag.doStartTag(LoadBundleTag.java:96)
at jsp_servlet._pages.__greeting._jspService(__greeting.java:145)

After looking around i saw the reason this happens because all JSF tags should be in the f:view tag and that you can't directly access a page with JSF tags (here)

Would this problem exist if someone tried to access your example directly (as opposed to being forwarded automagically to it.) If so, what’s the reason you can’t access the page directly? I did play around with the code a bit and moved the Loadbundle tag inside the view tag but the problem persisted when I accessed the page directly so maybe the explination is wrong or I am (mostly likely) missing something

Thanks, and good work as always!

This message was edited 3 times. Last update was at 01/29/2006 10:38:15

tfecw wrote:So my recommendation, when you get around to it obviously , would to cover setting up JSF. What jars do you need, what config files, changes the web.xml file, etc.
Perhaps if i get ambitious I’ll write something up (if you don't mind)

This is an open forum - all members are welcome to write Java related articles to post here. These articles are not sticky on purpose to allow anyone to respond to them. I'm still not positive if this is the correct format to have technical articles but I like the interaction.

And now on to the next post

Ok, now on to the next post - sorry it took so long.

There are two commonly used implementations of JSF. The first one is the Sun Java Server Faces reference implementation. This was created by Sun as a part of the original JSR created for JSF. The other implementation is the Apache MyFaces implementation.

Both of these distributions implement the JSF JSR. MyFaces includes a bunch of additional classes and features showing some of the possibilities of the JSF framework.

For this very simple article it really doesn't matter which one you use. I'll pick the Sun RI but really it is just a different set of jar files. The Sun RI distribution contains almost all of the Jars you'll need. It does not the JSTL jars. I used the JSTL libraries from the Jakarta Taglibs project.

So our directory structure will look like the below. Remember that JSF is meant to be part of a Java web application and that will dictate our directory structure somewhat.

The last two jars listed are from the Jakarta taglibs. All the rest are part of the Sun RI.

To speed things up a little I'm going to attach a complete web application as a Jar file. This jar contains all the code and required jars and runs standalone. We'll go into it in more detail in the next post.

This message was edited 7 times. Last update was at 04/26/2006 16:16:46

Ok, lets talk a little bit about the last two JSP's.

The first, index.jsp is just a redirection to the JSF controlled pages:

So why not just have the web application welcome page, as specified in web.xml, be "/faces/input.jsp"? Because according the 2.3 Servlet specification which defines what a web application looks like the welcome-file specified within the web.xml must map to an actual resource. There isn't a physical file named /faces/input.jsp so we redirect to the "virtual" URL that includes /faces as part of it's path.

The other files is the "output" JSP. It is pretty simple:

This is the file that gets loaded after we have input our name. It looks similar to the input page other than it is a bit simpler. Again we use the same message bundle to output the messages.

But how does this all tie together? Two files, web.xml (the standard web application configuration information) and faces-config.xml. These two files work together to complete the JSF installation.

In web.xml, there are really only two things that need to happen. The JSF controller servlet needs to be loaded and it needs to be given a URL pattern that will be used to invoke it. In web.xml we have:

Working somewhat backwards from the definitions, the last two sections define the Faces servlet and the URL that invokes the faces servlet. These are pretty standard servlet configuration sections. The second context-param simply tells the faces servlet where to find it's configuration information.

But the first context-param has JSF do something kind of neat. It says that the state of a particular JSF interaction should be stored on the client. But how is it stored? Cookies? Nope, it is hidden in the form. Take a look at the HTML form code generated from our first page:

If you look at your own page you'll see that I chopped off a few hundred characters from the value of the hidden com.sun.faces.VIEW paramater. This is an internal parameter that JSF used to keep track of who is posting what when.

The last file is the most important. faces-config.xml tells JSF how to map JSP files. It does not need to be named that as you can see from the web.xml snippet above. It is a pretty simple file:

especially for our example. The two parts are very straight forward. The first section defines our one and only navigation rule. Basically it says that when you get the "action" with the value "greeting" you should navigate to /greeting.jsp. That's it. Remember that we had the submit for our form:

there is where we specified the action. An action can forward to a page or it can even call a method in a class. To me it is a very important part of JSF, one it shares with Struts to an extent.

The second part of the configuration file tells JSF about a bean that we want it to manage. It is our PersonBean which has a single parameter that we want JSF to worry about, personName. JSF expects this bean to follow, well, the JavaBeans specification which in this case means it needs to have a getPersonName() method returning a String and a setPersonName() method that takes a String.

And that is pretty much it. You have seen how a JSF application can declaratively do some error checking of parameters - you didn't do anything but tell it the requirements. Another very powerful concept is that we have externalized the flow of our web application. That is, nothing in input.jsp knows that we end up at greeting.jsp. JSF takes care of this through its configuration file. The huge advantage is that we have introduced some easily expressable flow into our pages that can be modified without ever touching the page itself. The page doesn't embed this information - all web flow is maintained in one place.

Please feel free to ask if anything isn't clear. Good luck!