7 Additional JSF and Java EE Technologies

In the following section, we’ll look again at CDI bean technology and the JSF view declaration language, Facelets. In the first part, we’ll make use of the dependency injection mechanism (annotation @Inject) to establish references between the different controller beans of the application. Additional UI components are required for the implementation of our view. Also required is the ability to check inputs for validity (validators), to convert (converters) and to display error messages (FacesMessages). In addition to this, we’ll familiarize ourselves with the concept of view parameters, which can be used to pass, convert and validate parameters – as we did for the UI components – when a view is loaded using a HTTP GET request. Finally, we will explore how Ajax can be used to improve view dynamics.

7.1 The @Inject Annotation

It was all the way back in the theory about Java EE that we first learned about the fundamental principle of dependency injection (DI). Now, we want to use it in our project. The basic idea is that we wish neither to explicitly create the beans ourselves nor to be responsible for their life cycle management in our application. Instead, these responsibilities should be undertaken by the application server (more accurately, the CDI container). Where we need a specific bean, we want simply to make a corresponding declaration and communicate to the application server – via an annotation – that it must provide the corresponding bean at precisely this point in runtime. The annotation used for this purpose is @Inject (package javax.inject.Inject). Let’s take the controller class EditCampaignController as an example. In it, we require a reference to an instance of the class CampaignListProducer, to enable us to include new campaigns in the campaign list.

import javax.inject.Inject;
...
public class EditCampaignController implements Serializable {
...
   @Inject
   private CampaignListProducer campaignListProducer;
...
}

We use the campaignListProducer variable within the EditCampaignController class without creating an object of the class with the new operator at all. In conventional Java programs, this would inevitably lead to the dreaded NullPointerException when executed. For Java EE applications, however, the application server makes sure a corresponding object is available at runtime. Classes that are to be injected in this way using a CDI container must possess a parameter-free constructor.

During this process, we must always pay attention the scope for which the the bean in question is declared. This will be determined for the bean in its class by an annotation (e.g. @SessionScoped) or inferred from the injection point. When using DI, the developer must be clear about whether, at a particular place, they wish to work with the same instance of a bean class or a new one. Failing to observe this point can have far-reaching impacts. We will discuss both the DI mechanism and the scope of CDI beans in our Cloud Tutorial CDI in a Day.

7.2  Text Input with Validation, Conversion and Error Messages

As an example of JSF input components, let’s take a look at two components for text input. Text inputs are essential for many input screens. If we are dealing with texts short enough to be entered in one text line, a text field (<h:inputText>) is used. For text passages with multiple lines, a text area (<h:inputTextArea>) is used instead.

<h:inputText> in a nutshell

Component for a one-line text input (text field)

Selected attributes:

id: Unique identifier of the text field

value: Content or value of the text field. Generally contains an EL expression that binds the text field to an attribute of a bean.

The binding of a bean property to an input component results in the current value of the property being shown when the component is displayed and reset when a new input is made. The binding is therefore relevant for both reading and writing the property. The following example could be used to input an international bank account number:

 

<h:inputText id="iban"value="#{donateMoneyController.donation.account.iban}">

</h:inputText>

JSF renders the <h:inputText> tag on the server’s side to an HTML <input> tag with the value text for the attribute type (<input … type="text" …  />). The attribute id enables us to assign a unique identifier for the UI component within the Facelet. Different UI components can then use the id to refer to one another. An example of this can be found a little later on in the chapter, under the heading Error Messages.

<h:inputTextArea> in a nutshell

Components for multi-line text inputs

Selected attributes:

id: Unique identifier of the component

value: Content or value of the text component. Generally contains an EL expression that binds the text area   to an attribute of a bean.

rows: Number of text rows

cols: Number of text columns

readonly: Restrict to read-only access

The <h:inputTextArea> tag is converted into a correspondingly configured <textarea> HTML tag. The component can be configured via a range of attributes. In the following example, we use a text area to display the URL of a donation form:

<h:inputTextarea 
	id="url" 
	rows="6" 
	cols="30" 
	readonly="true" 
	value="#{editDonationFormController.url}" 
/>

Validation

Checking the validity of data entered is a central element of any web application, since a failure to check can lead to undesirable side effects. For example, invalid inputs can cause runtime errors that lead to unhandled errors on the server. JSF therefore provides a number of small-scale standard validation options. These make it possible to check the length of a text input or the number area of a numeric input, or to clarify whether an input has actually occurred. Since these options are generally unable to handle the complexity of real applications, the developer is usually also required to program their own validators. However, we will stick to standard validators for the purposes of this application.

We intend only to carry out a rough validation in the first iteration of our implementation. Accordingly, the check we’ll be using most frequently is the one to determine whether an input has actually occurred. This can be requested using the <f:validateRequired> tag. It will then be applied to all input components into which this tag was embedded as a child.

<f:validateRequired> in a nutshell

This validator checks the existence of a value in an input component.

Selected attributes:

for: Contains the ID of the input component to be validated

The reference to the validator can take place via the attribute for or through the embedding of the validator tag in the tag of the input component. The following example uses the latter approach. The validator relates to the input field with the ID iban:

<h:inputText id="iban"
		value="#{donateMoneyController.donation.account.iban}">
	<f:validateRequired/>
</h:inputText>

Another option for validating inputs within our view is to check the data against a regular expression. The <f:validateRegEx> tag can be used to do this.

<f:validateRegex> in a nutshell

This valdator uses a regular expression to check the value of an input component.

Selected attributes:

for: Contains the ID of the input component to be validated

pattern: Regular expression

The following example tag applies to an input component with the ID bg_color and is used to check two things: one, that the value consists of an arbitrarily defined combination of upper case letters from A to F, lower case letters from a to f or numbers from 0 to 9; and two, that an overall minimum length of 6 characters is reached:

<f:validateRegex for="bg_color" pattern="[A-Fa-f0-9]{6}" />

We can also use validators to check number areas. Let’s say, for example, that we have a double value and want to make sure that it’s always in a certain range. We can use the <f:validateDoubleRange> tag to do so.

<f:validateDoubleRange> in a nutshell

This validator checks whether the value of an input component lies within a specified range.

Selected attributes:

for: Contains the ID of the input component to be validated

minimum: Minimum input value

maximum: Maximum input value

The following example checks whether the value entered is at least 10.0.

<h:inputTextid="a_targetAmount"
		value="#{campaignProducer.selectedCampaign.targetAmount}">
	<f:validateRequired/>
	<f:validateDoubleRange minimum="10.0"/>
</h:inputText>

If the input consists of text, we can check its length using the length validator (<f:validateLength>).

<f:validateLength> in a nutshell

This validator checks whether the value of an input component falls in a particular length interval (length = number of characters)

Selected attributes:

for: Contains the ID of the input component to be validated

minimum: Minimum length

maximum: Maximum length

The following example checks that the length of the input is a minimum of 4 and a maximum of 30 characters.

<h:inputText id="a_name" value="#{campaignProducer.selectedCampaign.name}">
	<f:validateRequired/>
	<f:validateLength minimum="4" maximum="30"/>
</h:inputText>

Converters

In many cases, a conversion must take place before any validation can be carried out. HTTP communication is based on strings, while beans and validators generally use other types of data. In the example above, a conversion is not necessary only because the name property of the Campaign class is of the type String. The converter attribute of input and output components can be used to register converters for components. For this to occur, the converter attribute must contain the ID of the converter as a value. Alternatively, the tag <f:converter> can be used as a child element, whereby its id attribute activates a particular converter for the enclosing components.

JSF offers converters for standard data types. These converters are located in the package javax.faces.convert. ‎Tab. 4-2 lists the non-configurable converters with data type and converter ID.

Converter Java Type ID
BigDecimalConverter BigDecimal javax.faces.BigDecimal
BigIntegerConverter BigInteger javax.faces.BigInteger
CharacterConverter Character javax.faces.Character
BooleanConverter Boolean javax.faces.Boolean
ByteConverter Byte javax.faces.Byte
ShortConverter Short javax.faces.Short
IntegerConverter Integer javax.faces.Integer
LongConverter Long javax.faces.Long
FloatConverter Float javax.faces.Float
DoubleConverter Double javax.faces.Double

Tab. 4-2     Non-configurable JSF standard converters

The standard converters are applied automatically when an input component is bound to a bean property of another type.

There are two other converter classes for the conversion of dates and numbers. The behaviour of these converters can be configured. The DateTimeConverter enables the conversion of a java.util.Date object into a range of date formats as strings (and vice versa). The converter can be embedded in the Facelet using the tag <f:convertDateTime>. Configuration takes place via attributes of the tag. Since we do not wish to use this converter, we’ll refrain from going into any more detail about it here.

The converter class NumberConverter, meanwhile, enables the same powerful formatting of numbers. This converter can be integrated in a Facelet using the tag <f:convertNumber>. We have already seen an example of how numbers can be interpreted as currency amounts, since this occurred in the first use case.

The following example shows another conversion of numbers. Before being validated, the input here is converted into a number with exactly two places after the comma:

<h:inputText id="a_targetAmount" 
		value="#{campaignProducer.selectedCampaign.targetAmount}">
	<<f:convertNumber maxFractionDigits="2" minFractionDigits="2"/>
	<f:validateRequired/>
	<f:validateDoubleRange minimum="10.0"/>
</h:inputText>

As we did with the validators, we can also program our own converters to meet specific requirements.

We have now covered how validators and converters can be added to Facelet UI components. However, we have not explained how the user receives the information that their input has violated a validation rule or that a conversion has failed. This will be discussed in the next section.

Error Messages

Validations and conversions can both cause errors. These errors must be displayed to the user to allow them to correct their input accordingly. JSF defines a multi-lingual set of error messages for some typical problems that can occur with the different input components. Here, JSF differentiates between messages generated specifically for a single component and messages generated for the entire view. In addition, some error messages have both a short and a long form. Through the components, it is possible to overwrite standard error messages with your own. In the following example, an error message is set using the validatorMessage attribute of the text input.

<h:inputText id="a_name" value="#{campaignProducer.selectedCampaign.name}"
	validatorMessage="The name must be at least 4 and max. 30 characters long.">
	<f:validateRequired />
	<f:validateLength minimum="4" maximum="30" />
</h:inputText>

Of course, it’s also possible to store your own error messages again in properties files for the supported languages.

Error messages can be displayed on the page using special tags. The <h:message> tag is provided for displaying the error message of a particular component.

<h:message> in a nutshell

Displaying a message/error message for an individual component

Selected attributes:

for: References the component whose messages should be displayed

style: CSS style of the displayed message

The error message can be individually configured using other attributes. In the following example, we use the attribute style to present the error message in the color red. Special attributes of the tag can also be used to determine the formatting of the error output according to its degree of severity. The error message appears at the location you positioned the tag. In the following example, that location is directly below the input field.

<h:inputText id="name"
		value="#{donateMoneyController.donation.donorName}">
	<f:validateRequired />
</h:inputText>
<h:message for="name" style="color: red;" />

The <h:messages> tag can be used to display all of a page’s errors in a particular place. When requesting for the errors to be displayed, you can choose whether only global (that is, component-independent) errors are shown, or whether errors assigned to specific components should be displayed as well.

<h:messages> in a nutshell

Display all messages/error messages of a view

Selected attributes:

globalOnly: Display only the component-independent messages of the page (Default false).

showDetail: Display the detailed form of the message (Default false)

showSummary: Display the short form of the messages (Default true)

style: CSS style for the display

The selection of errors displayed can be controlled by the attribute globalOnly. While the tag always displays the long form of the message, you can use the showDetail and showSummary attributes of to switch between the long and short forms of the message. The following tag would represent the short forms of all the error messages associated with a particular view.

Behind the scenes, error messages are represented by the class FacesMessage in the package javax.faces.application. Thus, error messages can also be created directly in the program code of the backing beans. It is possible for us to create error messages with varying grades of severity. The constants for this grading are also defined in the class FacesMessages: SEVERITY_ERROR, SEVERITY_FATAL, SEVERITY_INFO, SEVERITY_WARN. The above standard validators create errors of the severity grade SEVERITY_ERROR. Error messages created in the Java code are also displayed by the above-mentioned <h:message> and <h:messages> tags. As we have already mentioned, special attributes of the tags can be used to format the error outputs differently according to their degree of severity.

Each error message relates to a specific request of a JSF page. In JSF, the status of a request – including all information for the generation of the response – is managed in an object of the class FacesContext from the package javax.faces.context. This object also contains the error messages. Error messages created in the Java code of the backing beans must therefore be added to the current instance of FacesContext. What follows is an example of how we can get access to the current instance of FacesContext in a backing bean and how an error message can be added.

FacesContext.getCurrentInstance().addMessage(null, 
		new FacesMessage(FacesMessage.SEVERITY_INFO, "Thank you for your donation!", null));

The tag <h:message> or <h:messages> will include this message when the response page is generated.

7.3 The Grid Layout of UI Components

A frequently used technique in views is the alignment of UI components to a grid. The <h:panelGrid> tag maps the UI components to a grid and is rendered as a table in HTML.

<h:panelGrid> in a nutshell

This tag enables the alignment of components to a grid structure and creates an HTML table.

Selected attributes:

columns: Number of columns per row

The components within the <h:panelGrid> tag are allocated to the grid row-by-row from left to right. If there are multiple components to be displayed within a grid element, they can be grouped using the h:panelGroup tag and the whole group allocated to that element. The following example shows the creation of an HTML table with two rows and two columns. The values of the value attribute are assigned to the four cells of the table from left to right and from top to bottom.

...
<h:panelGrid columns="2">
	<h:outputLabel value="topleft"></h:outputLabel>
	<h:outputLabel value="topright"></h:outputLabel>
	<h:outputLabel value="bottomleft"></h:outputLabel>			
	<h:panelGroup>
		<h:outputLabel value="bottom"></h:outputLabel>
		<h:outputLabel value="right"></h:outputLabel>
	</h:panelGroup>
</h:panelGrid>
...

7.4 Choice Components

Forms are required not only to provide the option for entering free text, but also to offer a choice between one or more predefined values or to enable certain options. JSF provides a variety of components to help us implement this. In the following section, we’ll take a closer look at two of these components, both of which are required for our implementation.

The Combo-Box (h:selectOneMenu)

Our first component enables the user to select one option from a list of predefined values.

<h:selectOneMenu> in a nutshell

Component for selecting a value from a list

Selected attributes:

id: Unique identifier of the component

value: Content or value of the combo box. Generally contains an EL expression that binds the combo box to an attribute of a bean. The current value of the bean attribute is displayed to the user.

The combo box is displayed in such a way that the currently selected value is the only one visible to the user. As soon as the user clicks on the selection bar, all of the possible choices appear. Java refers to this as a combo box, as do other GUI frameworks. The <h:selectOneMenu> tag is rendered to HTML as a <select> tag with the attribute size that has the value 1. The <f:selectItem> tag can be used within the <h:selectOneMenu> tag to specify the possible values.

<f:selectItem> in a nutshell

Component for representing a value from a list of choices/drop-down list

Selected attributes:

itemLabel: a visible representation of the value for the user

itemValue: The actual value of the choice, which is also used as a result for the bound bean attribute

The <f:selectItem> tags are rendered to HTML as <option> elements. The following example shows a choice of three elements:

<h:selectOneMenu id="bgColor"
		value="#{editDonationFormController.bgColor}">
	<f:selectItem itemLabel="#FFFFFF" itemValue="FFFFFF" />
	<f:selectItem itemLabel="#000000" itemValue="000000" />
	<f:selectItem itemLabel="#FF0000" itemValue="FF0000" />
</h:selectOneMenu>

The Checkbox <h:selectBooleanCheckbox>

Our second component enables the checking or unchecking of an option. This graphic component is also known as a checkbox. It is embedded in the view using the <h:selectBooleanCheckbox> tag.

<h:selectBooleanCheckbox> in a nutshell

Component for checking or unchecking a non-compulsory option

Selected attributes:

value: Content or value of the checkbox. Generally contains an EL expression that binds the checkbox to a boolean attribute of a bean.

If the graphical box is activated by the user, the value is set to true. If not, it is set to false. In the example below, the tag is followed by a text that explains to the user the consequence of checking a particular box within the application.

<h:selectBooleanCheckbox 
		value="#{donateMoneyController.donation.receiptRequested}"/> Yes, I would like a donation receipt.

 7.5 GET Parameter Processing in a View

JSF offers a mechanism by which the parameters of an HTTP GET request in a view can be directly bound to the properties of a bean. In principle, therefore, the setting of parameters works in exactly the same way as the setting of values from other input components. The values can be converted and validated using the same methods. The parameters are declared in the metadata of the Facelet within the <f:metadata> tag, which is located in the page’s <h:head> tag. The <f:viewParam> tag can be used to request a view parameter.

<f:viewParam> in a nutshell

Component that represents a parameter of an HTTP GET request

Selected attributes:

id: Unique identifier of the component

name: Name of the GET parameter of the request

value: Generally contains an EL expression that binds the parameter to an attribute of a bean

Converters and validators can be bound to the properties of backing beans in the same way as the text inputs and displays we looked at earlier. The following code snippet shows the declaration of a parameter with the name bgColor, which is adopted as the value of a backing bean property directly following successful validation. Its value is also validated by a regular expression.

...
<h:head>
	<title>Geld Spenden</title>
	<meta charset="utf-8"/>
	<f:metadata>
		<f:viewParam id="bgColor" name="bgColor"
				value="#{donateMoneyController.bgColor}">
			<f:validateRegex pattern="[A-Fa-f0-9]{6}"/>
		</f:viewParam>
	...
	</f:metadata>
</h:head>
...

7.6  Ajax – In Need of a Little More Dynamic?

We have so far experienced JSF in a very static way. The JSF tags are converted into HTML and the applications work strictly according to the page-oriented request-response principle: an HTTP request returns an HTML page. New requests are sent to the server using the page’s links and buttons and new complete HTML pages are returned. This method of processing has the result that the application is sometimes a little cumbersome for the user to operate. With each click, the page is requested, sent and displayed – despite the fact that the section of the page to be updated is sometimes only small. A few years ago, the development of Ajax (Asynchronous JavaScript and XML) brought us a general concept for increasing the interactivity of web applications. It works by ensuring that user actions result only in changes to the relevant parts of a page that is already displayed. Through partial requests, a section of the page is furnished with new data and its appearance updated accordingly instead of a completely new page being requested. The experience of the user is significantly enhanced as a result of the shorter response times. The technology enables web applications to be designed in the style of desktop applications and not merely as a series of linked web pages.

Ajax itself is based on a wide range of technlogies. The most important aspect, however, is that JavaScript is used alongside HTML in the browser. The JavaScript code communicates with the server via standardized interfaces, with the communications taking place parallel to the conventional HTTP request-response protocol. On the client side, JavaScript carries out the rendering of the page section to be updated.

The JavaScript API provided by JSF forms the basis for the integration of Ajax in Java EE applications. Developers can use this API directly or opt for the declarative variant through the tag <f:ajax>. We can equip a UI component with Ajax functionality by including the <f:ajax> tag as a child element in the declaration of the component. The exact actions of the <f:ajax> tag can be determined using its attributes.

<f:ajax> in a nutshell

This tag is used to determine the “Ajax behavior” of other components. Ajax behaviour is activated in a component by embedding this tag. For multiple components, the <f:ajax> tag can be used to enclose the components.

Selected attributes:

execute: List of components of the view that should run through all processing stages of the Faces request up to rendering within an Ajax request

render: List of components of the view that should only be executed for the rendering at the end of an Ajax request

The following code snippet shows the use of the <f:ajax> tag within a URL display that is dependent on a choice in a combo box. The tag is used to update the page without having to completely reload it.

...
<h:outputLabel value="Textfarbe:"></h:outputLabel>
<h:selectOneMenu id="textColor"
		value="#{editDonationFormController.textColor}">
	<f:selectItem itemLabel="#FFFFFF" itemValue="FFFFFF" />
	<f:selectItem itemLabel="#000000" itemValue="000000" />
	<f:selectItem itemLabel="#FF0000" itemValue="FF0000" />
	<f:ajax render="url" />
</h:selectOneMenu>
...
<h:inputTextarea <strong>id="url"</strong> rows="6" cols="30" readonly="true"
		value="#{editDonationFormController.url}" />
...

To understand this snippet, we must keep in mind that a dependency exists between the values of properties textColor and url of the bean EditDonationFormController. If we change the value of textColor, the value of url also changes. Following a change in the combo box value with the ID  textColor, the <f:ajax> tag ensures that only the JSF component with the ID url (that is, the text area component) is updated.

In order to completely understand the processing of Ajax requests in the context of JSF, we must be familiar with the processing model of a Faces request and how it is modified with respect to an Ajax request. This model is very complex, and a proper explanation would go beyond the scope of this chapter. For this reason, we recommend you to take a look at JSF specialist literature like Leonard, 2014.

 7.7 HTML5-Friendly Markup

JSF 2.2 uses HTML5 to provide an improvement in page rendering. This means that by default, a Faces request is answered by an HTML5 page, which an experienced web developer will be able to recognize easily from the first line (<! DOCTYPE html >).

HTML5 adds new attributes to a number of existing HTML tags. These attributes include the type attribute of input elements, which can be used to store semantic information about the type of input. Supported values here include text, search, email, url or tel.

Additionally, it is also possible to attach metadata to HTML elements that are not represented in the browser but can be requested with JavaScript. In the HTML specification, this mechanism is referenced with the designation custom-data-attribute. This attribute does not have a fixed name, but always begins with the prefix data-. Both of these HTML5 improvements enable web clients to interpret data semantically.

JSF UI components do not support these new attributes automatically. Upon first noticing this, we might think of it as something that should be corrected within a new version. On closer inspection, however, we see that this is completely unnecessary, since JSF either does not interpret these attributes during rendering or must convert them into HTML.

Rather, it would be useful to provide a general mechanism with which any pair of attribute names and values can be specified, but then passed along to the components responsible for rendering. Since we are dealing with metadata that is interpreted by the web client and not on the server side, this option is a viable one. Thus, JSF simply passes the attributes (with their values) to the HTML5 client, giving the mechanism its name: pass-through attributes. This enables JSF to use HTML5 extensions without having to re-implement its own components.

Let’s look at the following example. In HTML5, INPUT elements have a new attribute, placeholder. This attribute can be used to place text in the input field in gray until the field receives focus. This enables the implementation of very simple inline labels: labels of input fields that are not located over or before the respective field but are contained within the field itself. This is useful in that it allows us to provide informational texts for filling out an input field.

The attribute placeholder does not exist for JSF components like <h:inputText>. With the help of the pass-through mechanism, however, the new functionality can still be used in the client. In chapter 8, we will introduce a Facelet for editing and creating campaigns (editCampaign.xhtml). This contains a number of text fields, including one for entering the name of a campaign. We can determine an inline label for this field as follows:

...
<h:inputText id="a_name"
		value="#{campaignProducer.selectedCampaign.name}"
		validatorMessage="The name must be at least 4 and max. 30 characters long.">
	<f:passThroughAttribute name="placeholder"
			value="Name of the campaign" />
	<f:validateRequired />
	<f:validateLength minimum="4" maximum="30" />
</h:inputText>
...

After rendering, the resulting HTML5 page features an input field containing the attribute placeholder with the specified value:

<input id="j_idt8:a_name" type="text" name="j_idt8:a_name" 
	placeholder="Name der Spendenaktion" />

In this way, new HTML5 capabilities can be integrated in the result of the rendering. The HTML5-capable browser then takes care of the corresponding interpretation of the attributes.

Discussion

Use the message board below to give the authors your feedback or to discuss this page’s topic with other readers (in English please!). Please don’t expect the authors to answer directly, but they might update the content of this site according to your feedback.