Need to learn JSF in a hurry? I'm here to help!
Assuming you already have some Java experience, as well as some HTML experience, there is nothing to JSF, you can learn the basics in a few minutes. I also assume that you are familiar with packaging and deploying Java code to an application server such as GlassFish, WildFly, JBoss, Weblogic or Websphere, or to a servlet container such as Tomcat or Jetty.
JSF has evolved over the years, this blog post covers the best practices in JSF 2.0 or newer, specifically, Facelets is used to develop the front end (as opposed to JSP) and CDI Named beans are used to develop the server side code (as opposed to managed beans).
Step 1: Develop Java class(es) that will hold information (the Model in the MVC pattern)
Your Java class will be a Plain Old Java Object (POJO), it will consist of private properties public setters and getters.
package com.ensode.jsfinahurry.model;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;
@Named
@RequestScoped
public class Person {
private String firstName;
private String lastName;
private Short age;
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
public Short getAge() {
return age;
}
public void setAge(Short age) {
this.age = age;
}
}
The @Named annotation designates the class as a CDI managed bean, gives it a name, which by default is the class name with its first character switched to lowercase (“person”, in our case). This annotation allows JSF pages to access our Java class.
The @RequestScoped annotation gives our CDI bean a scope of request. If you have developed web applications in Java before you should be familiar with bean scopes by now.
The following table shows the most commonly used scopes for CDI named beans:
| Annotation | Scope |
| @RequestScoped | Request |
| @SessionScoped | Session |
| @ApplicationScoped | Application |
| @ConversationScoped | Conversation |
| @FlowScoped | Flow |
| @Dependent | Dependent pseudo scope |
The first three should be self-explanatory, the last two (@ConversationScoped and @FlowScoped) are both meant for the bean to live throughout two or more requests, but not last through the whole session. Since we're in a hurry, I can't explain these in detail, but suffice to say that @FlowScoped was introduced in JSF 2.2 as part of Java EE 7 and is the preferred way to achieve this functionality if you are using JSF 2.2 or newer. @Dependent just means that the bean will be created as needed.
Step 2: Develop a controller class
This is the controller in the Model-View-Controller (MVC) design pattern. As far as plumbing, there is not much to do for controllers, just use the @Named annotation and an appropriate annotation.
package com.ensode.jsfinahurry.controller;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;
@Named
@RequestScoped
public class PersonController {
public String processData(){
//in a real application, we would process user-input here
//more than likely saving data to a database
return "confirmation";
}
}
Our JSF pages will invoke the processData() method when the user clicks on a button, via a method binding expression (next section). By convention, the next page to render in the browser will match the return value of the invoked method (processData(), in our case). For our example, we will develop a page named confirmation.xhtml (matching the return value of “confirmation”) that will be rendered after our processData() method is invoked.
Step 3: Develop the pages
Now that we have our Java code in place, we need to develop the user interface. JSF pages are developed using Facelets, a JSF specific view technology. Facelets pages are nothing but standard XHTML pages using some JSF specific name pages.
A page used to allow the user to enter person data (to be stored in our Person class) may look like this:
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://xmlns.jcp.org/jsf/html">
<h:head>
<title>Enter Person Data</title>
</h:head>
<h:body>
<h3>Enter Person Data</h3>
<h:form id=”personForm”>
<h:panelGrid columns="2">
<h:outputLabel for="firstName" value="First Name"/>
<h:inputText id="firstName" label="First Name" value="#{person.firstName}"/>
<h:outputLabel for="lastName" value="Last Name"/>
<h:inputText id="lastName" label="Last Name" value="#{person.lastName}"/>
<h:outputLabel for="age" value="Age"/>
<h:inputText id="age" label="Age" value="#{person.age}"/>
<h:panelGroup/>
<h:commandButton value="Submit" action="#{personController.processData()}"/>
</h:panelGrid>
</h:form>
</h:body>
</html>
If you know even basic HTML, you should have a pretty good idea of how the above Facelets markup works. Before explaining the markup, notice that most JSF specific tags on the page have an id attribute. This attribute is optional, but it is a good idea to set it, for starters, it allows us to link labels to input fields (explained below), but also, when things don't work as expected it is much easier to identify which tag is causing trouble, as most JSF error messages will display the id of the component (if we don't set it, JSF will assign one, that will be meaningless to us).
The <h:head> and <h:body> tags are drop-in replacements for HTML <head> and <body> tags.
<h:form> is equivalent to the HTML <form> tag, notice that for JSF we don't need to specify the method and action attributes (method will always be “post” and the action will always point to the JSF servlet, which is automatically used when developing with JSF).
The <h:panelGrid> component lays out JSF tags on the page, similar to using a table to lay out HTML tags. Its column attribute specifies how many tags will be placed in each column.
<h:outputLabel> renders an HTML <label> tag, its “for” attribute must match the id attribute of the input component the label is meant for.
<h:inputText> is equivalent to an HTML <input> tag with a type of “text”. A nice thing about JSF is that it automatically converts user-entered values to the appropriate type in the corresponding CDI named bean. The value of the value attribute is what is known as a value binding expression, we can recognize these since they are encapsulated in curly braces and preceded by a hash (i.e. #{..}). Value binding expressions are used to automatically populate the corresponding attribute in a CDI named bean with the user-entered value for the corresponding input text. Remember the @Named annotation? “person” inside each value attribute corresponds to the name of our Person bean. The value after the dot corresponds to the corresponding property in the Person bean. For example, #{person.firstName} corresponds to the firstName property of the Person bean.
<h:panelGroup> is used to group JSF tags together in a single cell. In our case, all we wanted to do was have an empty cell so that our button would vertically align with the rest of the input fields, so we placed an empty <h:panelGroup> tag at the appropriate location in our <h:panelGrid>.
Finally, <h:commandButton> submits our form, its value attribute sets the label for the button, its action attribute indicates which CDI named bean method to execute when the button is clicked (processData(), in our case). This is what is called a method binding expression. The method must be public, return a String and take no arguments. What we implemented here is what is referred to as dynamic navigation, although our simple example always returns the same String, there is nothing stopping us from returning different values depending on some conditions, we can then take the user to different pages depending on these conditions (picture a switch statement or if/then/else, with different return values for different conditions).
If we don't need to do any processing after the user clicks the button and we always will display the same page, we can use static navigation, in which case the value of the action attribute can be hardcoded, like this:
<h:commandButton value=”Submit” action=”somepage”/>
We know that the value is hardcoded and not an expression since it is not surrounded by curly braces preceded by a pound sign (“#{...}”). In this case a page named somepage.xhtml would be rendered on the browser every time the user clicks on the button.
The markup for our confirmation page simply displays the values the user entered on the previous page.
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://xmlns.jcp.org/jsf/html">
<h:head>
<title>Confirmation Page</title>
</h:head>
<h:body>
<h3>You entered the following data</h3>
<b>First Name:</b> ${person.firstName}<br/>
<b>Last Name:</b>${person.lastName}<br/>
<b>Age:</b>${person.age}
</h:body>
</html>
The only thing new on this page is the use of curly braces preceded by a dollar sign (“${...}”) to retrieve a named bean's properties. When the page is displayed the value of the corresponding property is displayed on the page.
Our application in action
Once we package our application in a WAR file and deploy it to our application server of choice (I'm using GlassFish), our input page will be rendered. Here is what it would look like after a user entered some data:
Notice that we didn't have to specify any mappings in web.xml (as a matter of fact, web.xml is optional in modern JSF applications). By default, JSF pages are mapped to the /faces prefix.
When the user clicks on the Submit button, the processData() method on our PersonController class is executed, which takes us to the confirmation screen.
What I left out
This post is meant as a quick introduction to JSF, so I obviously did not cover every JSF nook and cranny. There are lots of additional JSF tags that I didn't cover, there are JSF specific equivalents to every HTML input tag.
JSF also has input validation built-in, we can make fields required and also accept only specific formats, for example. For application specific cases, we can develop our own custom validators.
JSF has built-in data conversion, we saw this in action by adding a property of type short and having the user-entered value automatically converted to the appropriate type. JSF also allows us to develop custom data converters.
JSF also has Ajax integration built in, a topic that I obviously didn't cover.
Finally, almost nobody develops “raw” JSF applications, the beauty of JSF is that allows the creation of component libraries. Most JSF applications employ one of these component libraries. Some of the most popular include PrimeFaces, RichFaces and IceFaces.
Where to go from here
After reading this short blog post, you should have a pretty good idea of the basic mechanics of JSF. To learn more about it, I'd be very grateful if you purchased one my books, Java EE 7 Development With GlassFish 4 or Java EE 6 Development With NetBeans, or, if you need personalized training, I can help you with that as well, just head over to my company web site: http://www.ensode.com for my contact information.
Of course, there is a ton of free information on the web as well, now that you know the basics other tutorials out there that assume basic knowledge should make more sense, just use your favorite search engine to find out more.
The source code for the example shown in this post can be downloaded here.
