Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 5
The custom validator used in Listing 1 is listed in Listing 2.
package com.sabreware.validators;
import java.util.Iterator;
import javax.faces.component.UIComponent;
import javax.faces.component.AttributeDescriptor;
import javax.faces.context.FacesContext;
import javax.faces.context.Message;
import javax.faces.context.MessageImpl;
import javax.faces.validator.Validator;
public class NameValidator implements Validator {
public AttributeDescriptor getAttributeDescriptor(String attributeName) {
return null;
}
public Iterator getAttributeNames() {
return null;
}
public void validate(FacesContext context, UIComponent component) {
String name = (String)component.getValue();
if(!"phillip".equalsIgnoreCase(name)) {
context.addMessage(component,
new MessageImpl(Message.SEVERITY_ERROR, "bad username",
"The username " + name + " is invalid"));
}
}
}
The preceding validator implements the javax.faces.validator.Validator interface, which defines the methods listed below:
void validate(FacesContext, UIComponent)Iterator getAttributeNames(String)AttributeDescriptor getAttributeDescriptor(String)The validate() method performs the actual validation for a given component. The other two methods, defined by the Validator interface, are used by tools to discover attributes (and their descriptions) associated with a particular validator. In this
case, we don't have any attributes for our validator, so the getAttributeDescriptor() and getAttributeNames() methods simply return null.
A validator's validate() method does nothing if the component's values are valid; if those values are invalid, the validator() method creates messages and adds them to the JSF context. All of that happens during the JSF lifecycle's Process Validations phase. If a component fails validation—meaning messages have been added to the JSF context—the JSF implementation proceeds
directly to the Render Response phase; otherwise, the lifecycle proceeds to the Apply Model Values phase. (Refer to Figure 1 for more information about the JSF lifecycle phases.)
In a Model-View-Controller (MVC) architecture, views, which are typically JSP pages for Java-based Web applications, display values contained in a model. JavaServer Faces makes it easy to connect UI components to fields stored in model objects. As we saw in the last section, if a request's values are all valid, the JSF lifecycle moves from the Process Validations phase to the Apply Model Values phase. During the latter phase, the JSF implementation copies component values to the model objects associated with those components. The HTML text fields shown in Figure 4a are connected to a model object. When the Log In button activates, the JSF implementation forwards control to a JSP page that uses that model object to display a personalized greeting (Figure 4b).
Figure 4a. HTML text fields connected to a model object. Click on thumbnail to view full-size image.
Figure 4b. Personalized greeting. Click on thumbnail to view full-size image.
Listing 3 shows the JSP page illustrated in Figure 4a.
SUBHEAD2: Listing 3. /index.jsp
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>A Simple JavaServer Faces Application</title>
</head>
<body>
<%@ taglib uri="http://java.sun.com/j2ee/html_basic/" prefix="faces" %>
<font size="4">Please enter your name and password</font>
<!-- We use jsp:useBean to create a model object, but
real applications typically create model objects elsewhere:
JSP pages are purely views of the model -->
<jsp:useBean id='user' class='com.sabreware.beans.User'
scope='session'/>
<faces:usefaces>
<faces:form id="simpleForm" formName="simpleForm">
<table>
<tr>
<td>Name:</td>
<td><faces:textentry_input id="name"
modelReference="${user.name}"/></td>
</tr>
<tr>
<td>Password:</td>
<td><faces:textentry_secret id="password"
modelReference="${user.password}"/></td>
</tr>
</table>
<p><faces:command_button id="submit" commandName="Log In"/>
</faces:form>
</faces:usefaces>
</body>
</html>
The preceding JSP page creates a session-scope variable of type com.sabreware.beans.User. JSP pages typically do not create model objects; instead, business objects, such as a servlet or a servlet filter, usually
create model objects. The preceding JSP page uses the <faces:textentry_input> tags' modelReference attribute to specify a field in the user object. For example, the name field is associated with the user object's name property, and the password field is associated with the user object's password property.
The User class is demonstrated in Listing 4.
package com.sabreware.beans;
public class User {
private String name = null, password = null;
public void setName(String name) { this.name = name; }
public String getName() { return name; }
public void setPassword(String pwd) { this.password = pwd; }
public String getPassword() { return password; }
}
The User class is a simple JavaBean that stores a name and password. Here's the JSP page shown in Figure 4b:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>A Simple JavaServer Faces Application</title>
</head>
<body>
<%@ taglib uri='http://java.sun.com/jstl/core' prefix='c' %>
Welcome to JavaServer Faces, <c:out value='${user.name}'/>!
</body>
</html>
The preceding JSP page accesses the name property of the user object created by the JSP page listed in Listing 3. That property is accessed with the JSP Standard Tag Library (JSTL). Note the exact same syntax is used in Listing 3 to specify
user properties with the modelReference attribute.
By itself, JavaServer Faces does not provide much support for internationalization; instead, JSF relies on JSTL for internationalization and localization support.
Java-based Web applications typically localize messages (and format or parse numbers, currencies, percents, and dates) in JSP pages. It's also common to localize messages in a Java class. A validator, for example, may localize error messages. This section discusses both approaches using JSTL to internationalize the Web application discussed in the previous "Model Objects at Work" section.
First, we store all localized text in a properties file:
login.window-title=Internationalization Javaserver Faces
login.name=Name
login.password=Password
login.submit=Log In
errors.bad-username=Bad username
errors.bad-username-details=The username {0} is invalid
Then we rewrite Listing 3's JSP page to localize all text displayed to the user. Listing 7 shows that rewritten JSP page.
<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.0 Transitional//EN'>
<html>
<head>
<%@ taglib uri='http://java.sun.com/jstl/fmt' prefix='fmt' %>
<fmt:setLocale value='en-US' scope='application'/>
<fmt:setBundle basename='messages' scope='application'/>
<title><fmt:message key='login.window-title'/></title>
</head>
<body>
<%@ taglib uri='http://java.sun.com/j2ee/html_basic/' prefix='faces' %>
<font size='4'>Please enter your name and password</font>
<jsp:useBean id='user' class='com.sabreware.beans.User'
scope='application'/>
<faces:usefaces>
<faces:form id='simpleForm' formName='simpleForm'>
<table>
<tr>
<td><fmt:message key='login.name'/></td>
<td><faces:textentry_input id='name'
modelReference='${user.name}'>
<faces:validator className=
'com.sabreware.validators.NameValidator'/>
</faces:textentry_input>
</td>
<td>
<faces:validation_message componentId='name'/>
</td>
</tr>
<tr>
<td><fmt:message key='login.password'/></td>
<td><faces:textentry_secret id='password'
modelReference='${user.password}'/></td>
</tr>
</table>
<p><faces:command_button id='submit' commandName='Log In'/>
</faces:form>
</faces:usefaces>
</body>
</html>
The preceding JSP page uses two tags from the JSTL formatting library to set a locale and resource bundle base name (<fmt:setLocale> and <fmt:setBundle>, respectively) and a third tag (<fmt:message>) to display localized messages stored in the specified resource bundle.
The validator listed below localizes error messages, also using JSTL.
package com.sabreware.validators;
import java.util.*;
import java.text.MessageFormat;
import javax.servlet.ServletContext;
import javax.servlet.jsp.jstl.core.Config;
import javax.servlet.jsp.jstl.fmt.LocalizationContext;
import javax.faces.component.UIComponent;
import javax.faces.component.AttributeDescriptor;
import javax.faces.context.FacesContext;
import javax.faces.context.Message;
import javax.faces.context.MessageImpl;
import javax.faces.validator.Validator;
public class NameValidator implements Validator {
public AttributeDescriptor getAttributeDescriptor(String attributeName) {
return null;
}
public Iterator getAttributeNames() {
return null;
}
public void validate(FacesContext context, UIComponent component) {
String name = (String)component.getValue();
if(!"phillip".equalsIgnoreCase(name)) {
ServletContext app = context.getServletContext();
LocalizationContext lc = (LocalizationContext)
Config.get(app, Config.FMT_LOCALIZATION_CONTEXT);
if(lc == null) {
context.addMessage(component,
new MessageImpl(Message.SEVERITY_ERROR, "bad username",
"The username " + name + " is invalid"));
}
else {
ResourceBundle rb = lc.getResourceBundle();
Object[] args = new Object[] { new String(name) };
String cs = rb.getString("errors.bad-username-details");
String s = MessageFormat.format(cs, args);
context.addMessage(component,
new MessageImpl(Message.SEVERITY_ERROR,
rb.getString("errors.bad-username"), s));
}
}
}
}
JSTL maintains a localization context that contains a resource bundle and the locale used to locate that resource bundle. That localization context is available
through the JSTL Config class. The preceding JSP page uses the context's resource bundle to localize messages.