Chapter 1. Introduction

The major benefit of the JSF framework is a component based architecture.
The component in JSF is not just a set of HTML code rendered and interpreted by a browser.
The JSF component is a combination of a client-side widget coupled with the server-side object
that represents component behavior including data validation, events handling, business layers bean binding, etc.

Comparing to a page-oriented development approach,
JSF allows to use a component-oriented paradigm to build a well-designed,
highly customizable UI interface based on reusable components.

However, there is not yet enough sets of rich components on the market that might enable the rapid application development.
One of the most important problems is a time-consuming and very complicated process of the component creation.
Even the very primitive JSF component requires the UIComponent class,
Renderer class, Tag class
and a faces configuration file (faces-config.xml) to be written.

In order to use the component library in a Facelets environment,
you should add the *.taglib.xml file to this checklist.

Creation of the rich component takes even more time.
You have to provide the ListenerTagHandler class, a class for creating a listener interface,
an event processing method name in a listener interface,
an event class, render specific classes for each possible render kit used with the component.

Therefore, the process of JSF component creation is pretty complicated but repeatable.
Jonas Jacobi and John R. Fallows in their "Pro JSF and Ajax Bulling Rich Internet Components" book describe
the process in details.
This description and used approaches are very similar to our own experience and have been used as a methodology
for Component Development Kit (CDK) - a sub-project of RichFaces
that allows you to easily create rich components with built-in Ajax support.

The significant features of the Component Development Kit (CDK) are:

Quick development start.
A new component development starts from a pre-generated component project template.
It contains the whole required infrastructure and necessary files generated.
It's necessary only to have a Maven installed.
All other required stuff will be loaded and configured automatically. For more information about how to
work with Maven on JBoss projects explore corresponding articles
at JBoss portal.

Declarative approach for a component development.
It's necessary only to specify meta-data and a code specific for your component.
All other required artifacts are generated for you.

Independent development life-cycle. Component Development Kit (CDK) presumes
development of each component isolated from each other with further assembling them into the component library.
Hence, this allows to organize a continuous process when one component is already in production condition,
but another is just started.

Possibility to create a first-class rich components
with built-in Ajax functionality
and add Ajax capability to the existing JSF applications.

Facility for automatic testing.
At the moment of generating the initial project structure,
the Unit Test classes are also generated.
The RichFaces also provides the Mock-test facility that allows to emulate
a run-time environment and automatically test components before their are gathered into the result library.

Optimization for different JSF implementations.
As soon as the most part of a result code is generated, the Component Development Kit (CDK)
becomes able to generate an implementation specific code along with a universal code.
It makes sense if it's necessary to optimize a result code using features specific for
the particular implementation. For example, for using with JSF 1.2 only.

Create a modern rich user interface look-and-feel with JSP-like templates and skins-based technology.
RichFaces comes with a number of predefined skins to get you started,
but you can also easily create your own custom skins.

Chapter 2. Roadmap document

This document is aimed to describe components development with the
Component Development Kit (CDK) and its features.

In order to be successful in Component Development Kit (CDK) usage and components development,
it's necessary to be acquainted with Java Server Faces and RichFaces framework.
To read more on these topics, please, follow the links:

After the Maven is installed you should configure it. In this case,
please, go to the directory where you've just installed Maven,
open a conf/settings.xml file for editing and add to the
profiles section this code:

Dependency scope is used to limit the transitivity of a dependency, and also to affect the classpath used for various build tasks.
"Provided" scope indicates you expect the JDK or a container to provide the dependency at runtime.
For example, when you build a web application with RichFaces,
you would set the dependency on the Servlet API and related libraries to scope
"provided" because the web container provides those classes.

Chapter 4. inputDate component development

We a going to create the <inputDate> component that can take a value, process that value, and then push it back
to the underlying model as a strongly typed Date object.

The <inputDate> component allows to attach a converter in order to set the desired date
format such as mm/dd/yyyy. So the component could convert and
validate the date entered by user.

4.1. Creating project for component

At first we need to create a project for the component itself. In the library directory
Sandbox you just created, launch the following command (all in one line):

4.2. Creating and building component skeleton

You need to go to the inputDate directory and then launch the
following command:

mvn cdk:create -Dname=inputDate

As a result three artifacts will be created:

An XML configuration file for the metadata

A UI class

A JSP-like template

In order to build the component you should stay in the inputDate
directory and launch the following command:

mvn install

This command generates and compiles the library and then creates a result JAR file. A
directory named target will be created along with a
src directory. If you get a file named
target/inputDate-1.0-SNAPSHOT.jar, everything is set up
successfully.

If you want to rebuild the component you could use the following command:

mvn clean install

4.3. Creating a UI prototype

It is a good idea to create at first a prototype of the intended markup. You will find out
which markup elements the component has to generate and also which renderer-specific
attributes are needed in order to parameterize the generated markup.

The <inputDate> component consists of an HTML form <input> element, an
<img> element, and <div> element:

...<divtitle="Date Field Component"><inputname="dateField"value="01 January 2008"/><imgclass="overlay"src="inputDateOverlay.png"/></div>...

All information about styles applied to the <inputDate> component is provided in the following chapter.

This is the result of your prototype which shows a simple page with an input field and an icon indicating that
this is a date field:

Figure 4.2. The date field component prototype implementation in HTML with an icon

4.4. Creating a Renderer

Component functionality typically centers around two actions:
decoding and encoding data.
Decoding is the process of converting incoming request parameters to the values of the component.
Encoding is the process of converting the current values of the component into the corresponding markup. In the
following figure you can see decoding and encoding occur in the JSF lifecycle:

Figure 4.3. Decoding and encoding in the JSF lifecycle

Thus, JSF components consist of two parts: the component class and the renderer.
The component class is responsible for the state and behavior of a UI component and will be discussed later in the "Configuring component" section.

The Renderer is responsible for the JSF component representation. It generates the
appropriate client-side markup, such as HTML, WML, XUL, etc. Renderer is also
responsible for the converting information coming from the client to the proper type
for the component (for example, a string value from the request is converted to a
strongly type Date object).

It is necessary to create following renderer classes for the <inputDate> component:

InputDateRenderer class where you should override encode() methods for encoding the markup and resources

InputDateRendererBase class where you should override decode() method.
You could also define associated converter in this class.

You could actually implement the renderer-specific component subclass that
exposes client-side attributes such as "style", "class", etc. It is common practice to implement the client-specific component
subclass to make some aspects of application development easier, but in our case we
do not need to do it. The <inputDate> is a simple UIInput component, therefore
InputDateRenderer class generates all the markup itself.

It is a time to start creating the InputDateRenderer class.
The smartest way to create the InputDateRenderer class is a Templating mechanism,
one of the most convenient features of the Component Development Kit (CDK).

4.4.1. Templating

The Component Development Kit (CDK) allows to use templates for generation Renderer class.

Templates are JSP-like markup pages with special tags that are converted into
Renderer by a build script.

It's possible to use evaluated expressions in components templates with the help of scriptlets.
It's also possible to create the base class for a template to
implement additional functions in it, so as the functions could be called from the template.
Hence, in the generated Renderer class there are corresponding function
calls on the place of these elements.

Let's create the template for HTML 4.0 markup. At first you should proceed to the
inputDate/src/main/templates/org/mycompany directory where
htmlInputDate.jspx template file is stored. This file contains a
Template Skeleton like this one:

<img> element with
"src",
"class",
"style" attributes which defines a default icon of the component.
In order to add an image to the Template you should register it with the help of
<f:resource> template tag
and bind to a variable specified by the "var" attribute:

Note:

As it is seen in the Template Skeleton the Renderer Baseclass is org.ajax4jsf.renderkit.AjaxComponentRendererBase.
You need to define Renderer Base class special for the <inputDate> component.
In the next section "Creating a Renderer Base class"
we will create Renderer Base class org.mycompany.renderkit.InputDateRendererBase.

4.4.2. Creating a Renderer Base class

After the component tree is restored on the Restore View Phase ,
each component in the tree extracts its new value from the request parameters
by using its decode() method. Then the value is stored locally on the component.

In order to create InputDateRendererBase class you should proceed to the
src/main/java/org/mycompany/renderkit
directory and create this class there:

The InputDateRendererBase class extends a HeaderResourcesRendererBase
class. In the HeaderResourcesRendererBase class all the encode() methods for
the right resources encoding
are already implemented, so in the InputDateRendererBase class you need to override
the decode() method only:

As you see in the example above the decode() method reads values from request parameters,
grabs the clientId from the component to identify the request parameter to be looked up.
The clientId is calculated as the fully qualified name of the component given its container path:
nameOfForm:nameOfComponent (for example myForm:inputDate).
The last step of the decode() method is to store the submitted value locally on the component.

Note:

By default, the base Renderer implementation returns the submittedValue directly without any conversion!
If you want to convert submitted value to a strongly typed object you should implement Converter
and the getConvertedValue() method in your Renderer class (in our case in the InputDateRendererBase class).

4.4.2.1. Creating a Converter

As it was mentioned before the <inputDate>
component at the Apply Request Values phase takes a value and pushes it
to the model as a strongly typed Date object.
Therefore you need to implement a Converter in the Renderer Base class and also check
whether a Converter has been already attached by the application developer.
If the conversion of the value fails, an error message associated with the component is generated
and queued on FacesContext.

The getConverter() method of the InputDateRendererBase class returns the a converter, as shown in the following example:

During the converter creation you should check whether the application developer has attached a Converter to the
<inputDate> component already
(for example, <f:convertDateTime>) .
If not you should follow the next steps:

create a new DateTimeConverter

get the locale for the client from the context with the help of the getLocale() method
and set it on the new Converter by means of the setLocale() method

set the time zone, date type, date style, and date pattern on the new converter with the help of
setTimeZone(), setType(), setDateStyle(), and
setPattern() methods respectively

return the Converter

After the Apply Request Values phase the application enters the
Process Validation phase during which the validate() method
calls the getConvertedValue() method on every submitted value and passes
the newly submitted value from the decode process.

The getConvertedValue() method converts the submitted value to a strongly typed
object (in our case Date) using the getAsObject() method.
Then the new strongly typed object is validated and if there are no errors
Process Validation phase ends. Otherwise the getConvertedValue() method
throws a ConverterException.

Finally on the Renderer Response phase the value of the component is rendered back to the view.
The converter is responsible for transforming the object data back in to a string representation, so you need to
implement getValueAsString() method:

4.4.3. Skinnability

One of the significant features of the Component Development Kit (CDK) is a skins-based technology which helps you to create a modern rich user interface look-and-feel.
RichFaces has a number of predefined skins you could use with the <inputDate> component.
But if you want to create your own skin, please, read carefully
the "Skinnability" section of the
RichFaces Developer Guide. You could find all necessary information about
Built-in skinnability in RichFaces, XCSS file format, Plug-n-Skin feature, etc. there.

It's time to create XCSS file. You should go to the src/main/resources/org/mycompany/renderkit/html/css
and create inputDate.xcss file there with the following skeleton:

4.5. Component resources registration

The <inputDate> component has a number of resources that should be registered
in the resource-config.xml file.
If the resource is registered, the RichFaces filter will send a request to the ResourceBuilder class
in order to create and to deliver the resource.

Hence, you need to proceed to the inputDate/src/main/config/resources directory and
register the following resources in the resource-config.xml file:

There are two elements in the example above:
an obligatory <name> element which defines resource name and
a <path> element which defines the path to the resource.
The <path> element is optional as it is possible to register
dynamic resources with the "class" attribute.
For example you could register a dynamically created image as it is shown in the following example:

With the help of the <cacheable> element
you could manage whether the resource is cached or not.
If the value of this element is "true", the resource is cached on the server and also on the client sides:

It is possible to specify a MIME type for the resource renderer
using the <content-type> element.

4.6. Extending a UIInput class

The base class for all JSF components is UIComponent.
When you develop <inputDate> component
you could see that you subclass UIComponentBase at first.
This class extends UIComponent, and provides default implementations of the all of the abstract methods of UIComponent.

You could proceed to the src/main/java/org/mycompany/component directory
and find a UIInputDate.java there:

Each component is associated with a component type,
which is used as "JSF recognized" name of the <inputDate> component.
We will refer to this later in our tag handler.

The component class is the actual class path address of our <inputDate> component.

As it was mentioned before, the <inputDate> component has some attributes
that are bound to the properties in the UIInputDate class
(for example title, name, type, etc.).
The next thing to do is to save the component state
by overriding saveState() and restoreState() component methods.
But you do not have to do it in the UIInputDate class by hand!

You should configure the <inputDate> component
in the inputDate.xml,
and the CDK factory will generate the complete UIInputDate class.
How to configure the component is explained in the "Configuring component" chapter.

4.7. Configuring component

Well, it is almost the final step in the component creation process - component configuration.

Note that you should register all the classes and attributes of the <inputDate> component.
If you will create the component dynamically on a page
you should register the component in the faces context configuration file - faces-config.xml.
If you use a custom tag on a JSP page you need a TLD file for registration.
If you plan to use Facelets you need inputDate.taglib.xml descriptor.

The CDK factory uses the inputDate.xml file
for generating not only the complete UIInputDate class,
but also a JSP Tag Handler, faces-config.xml and descriptors for JSP and Facelets.

Please, proceed to the src/main/config/component directory,
open the inputDate.xml in your favorite text editor
and take a look at the skeleton: there is a root element <components>
with the one nested <component> element.

Tip:

It is possible to create a number of components in the one project.
For example <rich:dataTable> is a complex component that
includes a <rich:column>
and/or <rich:columns> components.

Application instance stores resources defined in the descriptors at application start-up, so it is necessary to register
following classes:

Note that you have not closed the <component> element
because you are still going to add more metadata for your new component.
Lets to add attributes to the inputDate.xml configuration file as shown in the example below.

Example:

...<property><name>value</name><classname>java.lang.Object</classname><description> The value of the component</description></property><property><name>title</name><classname>java.lang.String</classname><description> Defines a title of the component</description><defaultvalue>&quot;inputDate&quot;</defaultvalue></property><property><name>name</name><classname>java.lang.String</classname><description> Defines a name of the component</description></property><property><name>styleClass</name><classname>java.lang.String</classname><description> Corresponds to the HTML class attribute</description></property><property><name>inputStyle</name><classname>java.lang.String</classname><description> Style attribute for input field</description></property><property><name>inputClass</name><classname>java.lang.String</classname><description> Style Class attribute for the input field</description></property><property><name>iconClass</name><classname>java.lang.String</classname><description> Style Class attribute for the icon element</description></property><property><name>iconStyle</name><classname>java.lang.String</classname><description> Style attribute for the icon element</description></property><property><name>captionClass</name><classname>java.lang.String</classname><description> Style Class attribute for the Caption facet</description></property>...

As you can see in the example above every attribute is defined with the help of the
<property> element with the following nested elements:

the <name> element that defines the name of the attribute

the <classname> element that defines the class of the attribute's value

the <description> element that defines the description of the attribute.
This description appears in the TLD file.

the <defaultvalue> element that defines the default value for the attribute

The last thing worth mentioning is the common attributes that are included through the named entities:

...&ui_component_attributes;...

If you want to add UIInput components and HTML events common attributes for the
<inputDate> component you should add the following entities:

...&ui_component_attributes;&html_events;&ui_input_attributes;...

In
inputDate.xml file there is a full example of the inputDate.xml for the
<inputDate> component.

4.7.1. Including common attributes

One of the useful features of the CDK is the possibility to include common attributes to the component.
In order to facilitate development process, the CDK provides a set of entities
that contain custom attributes sets for components (events, action attributes, etc.).
This common attributes could be included with the predefined entities
(for example &ui_component_attributes;,
&html_events;, &ui_input_attributes;, etc.).

4.8. Creating tag class and descriptors for JSP and Facelets

The last step is to create a JSP tag handler and descriptors.

JSF components are not inherently tied to JSP. You will use a custom tag (a.k.a action) on the JSP page to
indicate which JSF UIComponent is needed for the application.
The custom tag has a corresponding tag handler class, which is responsible for creating the UIComponent
and transferring each declarative JSP tag attribute to the UIComponent instance.
Hence you need a custom tag class that returns
the component type (org.mycompany.InputDate) and the renderer (org.mycompany.InputDateRenderer).

After the tag class creation you need to register it in the descriptors:
in the TLD (Tag Library Descriptor) file for JSP pages and
in the inputDate.taglib.xml file for Facelets.

But you know that inputDate.xml configuration file generates
the JSP tag handler and descriptors instead of you!
Just proceed to the inputDate folder and launch the following command:

mvn clean install

After the generation process you will find in the inputDate/target/classes/META-INF folder
inputDate.tld, inputDate.taglib.xml, resources-config.xml,
and faces-config.xml files.

The InputDateTag class could be found in the inputDate/target/classes/org/mycompany/taglib.

Well done! The <inputDate> component is created.
The inputDate-1.0-SNAPSHOT.jar for the component usage could be found in the inputDate/target folder.

Chapter 5. Component usage overview

After the <inputDate> component has been created you could use it on a page.
Create a simple JSF project, called myapp for example, with only one JSP page that has a form with our
<inputDate> component.

5.5. Deployment

Chapter 6. Developer sample creation

The RichFaces CDK allows you to create samples easier as it has been discussed earlier
in the "Component usage overview" chapter.
Let's create a simple JSF project, called inputDate-sample for example,
with the help of the maven-archetype-jsfwebapp archetype.

It is necessary to proceed to your Sandbox directory
where you have created the <inputDate> component
and launch the following command (all in one line):

As easy to see a new directory inputDate-sample is created with the predefined JSF project structure:

Figure 6.1. The predefined JSF project structure

It should be pointed out that maven-archetype-jsfwebapp archetype creates
skeletons of the following files:
JSP page,
Facelets page,
managed bean already registered in the faces-config.xml,
complete deployment descriptor (web.xml).

Now it is necessary to edit a JSP page, managed bean skeletons, and add the proper dependency
to the pom.xml file of the inputDate-sample project.

6.1. JSP Page

You should proceed to the inputDate-sample/src/main/webapp/pages directory
and edit index.jsp file.
You should add a form with our <inputDate> component.

6.3. pom.xml

In order to use any component on a page (JSF, Facelets, RichFaces, etc.) you should
add necessary libraries to the JSF project. Sometime it takes a lot of time to get
all the dependencies of a particular library. You should also prevent versions conflict if the
library already exists on a server.
Now we are going to add necessary libraries to the JSF project, deploy and run project on
a server. Maven will help us.

Maven is a high-level, intelligent build and deployment tool
designed to take much of the hard work out of the build process.
In Maven's Project Object Model (POM) file we could declare necessary
dependent libraries and Maven plugins used to manage all parts of the build process.

Our <inputDate> component depends on JSF and RichFaces
libraries.
If you declare inputDate dependency in
the inputDate-sample project's POM
all the necessary libraries will be added automatically.
Therefore you need to delete richfaces-ui artifact out of
dependencies first and then add only one inputDate dependency:

Now it is possible to build the inputDate-sample project with the help of the following command:

mvn install

The final step is to deploy and run the project on a server.
One of the convenient features of Maven is the Jetty plugin.
Jetty is an open-source web server implemented entirely in Java.
In order to deploy and run the project on the Jetty you should take the following steps:

Chapter 7. Generating unit tests

Unit testing is a method of testing that verifies the individual units of source code are working properly.
A unit is the smallest testable part of an application, method for example.

The goal of unit testing is to isolate each part of the program and show that the individual parts are correct.
Unit tests find problems early in the development cycle and allow you
to perform code refactoring at a later date, and make sure the module still works correctly.
By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

Unit testing provides a sort of living documentation of the system. You could learn unit functionality
by looking at the unit test and get a basic understanding of the unit API.

Note:

Unit testing cannot be expected to catch every error in the program.
It only tests the functionality of the units themselves.
Therefore it is more effective if the other software testing activities
are used in conjunction with unit tests.

Unit tests generated by CDK check all the properties of the component, resources availability,
and perform render test view.

In order to add unit tests to the project you should
take the following steps:

proceed to the inputDate/src/main/config/component directory,
open the inputDate.xml file

add the <test> element nested to
<component> in order to generate
unit test for the UIInputDate class

If all the tests have been run successfully, the "BUILD SUCCESSFUL" message will appear.

You could also find detailed tests information in the surefire reports placed in the
inputDate/target/surefire-reports directory.

Chapter 8. Creating projects in different IDEs

As you could have mentioned the process of the JSF component creation
is pretty labor-intensive but repeatable.
During the CDK Guide you have created a simple
<rich:inputDate> component.
However when creating components in the wild you need debugger, class browser,
object inspector, class hierarchy diagram, etc.
to simplify development process and maximize productivity.
In other words you need an IDE.

The question is what IDE is more suitable for the JSF component development.
There is no one answer for this question and the right of private judgment in matters of choosing IDE,
is better secured to us than to any other people in the world.

Eclipse IDE seems to be more preferable for
the rapid component creation process.

Tip:

8.1. Creating project in Eclipse IDE

During the development process you could be confronted with some difficulties.
For example, it is necessary to rebuild component every time
you want to check your work on it in a developer sample.
It is also hard to debug JavaScript scenario without IDE's help.

After that you need to build <rich:inputDate> component and
it's sample project for the import as existing Eclipse projects.
It is necessary to proceed to the Sandbox/inputDate and Sandbox/inputDate-sample
directories and launch the following command:

mvn eclipse:eclipse -Dwtpversion=1.5

The command you've launched above creates files and folders necessary for the import. The -Dwtpversion=1.5 key indicates
that you have Web application, so it should be possible to run it on a server.

Finally you need to make import. You can find a step-by-step tutorial at the
Eclipse documentation page
or simply in the Help > Help Contents of the Eclipse.
As the result two projects should appear in the workspace:

Figure 8.1. Projects in the workspace

Now it is necessary to define <rich:inputDate> component JAR
you have imported on the build path of the inputDate-sample project.

You need to select Properties of the inputDate-sample project,
proceed to the Java Build Path > Libraries tab
and then remove "inputDate-1.0-SNAPSHOT.jar" item.

Figure 8.2. Remove inputDate item from the Library

After that you need to proceed to the Java Build Path > Projects tab
and add already imported inputDate project.

Chapter 9. Naming conventions

During the development process,
the next naming convention for all project stuff should be mentioned.

At first take a look at the definitions that are used in this structure.
Uppercase symbols means Java names notation. For name "foo" <name> means "foo",
and <Name> - "Foo":

Table 9.1. The structure definitions

Definition

Description

<prefix>

A common library name for example, base JSF components use <javax.faces> prefix.
The value for prefix get from an abstract component package or a renderer template path.

<name>

A name for a base component.
For UIInput component <name> is "input".
The value for a component name generator could be obtained from UI or Abstract class name.

<markup>

A render-kit generated content name:
"html" for HTML/XHTML pages,
"wml" for mobile content, etc.
It should be provided in the render-kit description by Ant task
or in Maven's POM.
By default, "html" is used.

<rendererName>

A name of the renderer for concreting a visual component implementation, e.g. "commandButton" , "panelGroup", etc.
A generator can take <rendererName> from a template file name.

<event>

A name for a Faces Event: "action" for all
ActionSource components like UICommand.
It could be provided in the component configuration, or obtain from the implemented source interface.

Now let's take a look to the naming convention.
By default, a generator expects the written Java classes structure above:

Table 9.2. The Java classes structure

Naming convention

Description

<prefix>.component.Abstract<Name>

An optional abstract super-class for a JSF component.
In order to avoid manual writing for EL-enabled getters/setters, saveState/restoreState methods,
listener-related methods etc., you can create an abstract class, and a generator creates the implementation.

<prefix>.component.UIt<Name>

A Base component class. It can be generated from the abstract superclass or created by a developer.

<prefix>.component.<markup>.<Markup><RendererName>

A renderer-specific generated component.
The <Markup> is a render-kit specific generation name such as html,
xml, wml.
In addition to the UI Component class, this class contains Java Bean getter/setter methods
for renderer-specific attributes.
This class is generated by CDK.

<prefix>.t<Name>

A JSF UI component type. Can be provided in the configuration or calculated from a component class name.

<prefix>.<Markup><RendererName>

A renderer-specific JSF component type. Can be provided in the configuration or calculated from the renderer name.

<prefix>.renderkit.<RendererName>RendererBase

A Renderer Base class is an optional Renderer superclass,
implements methods from the template renderer.
Should be created by you.

<prefix>.renderkit.<markup><RendererName>

A generated Renderer

<prefix>.<RendererName>

A JSF renderer type. Can be provided in the configuration or calculated from a renderer name.

<prefix>.<Markup><RendererName>.xml

A template for generating the renderer class.
JSPX syntax is used. Should be provided by you.

<prefix>.taglib.<RendererName>Tag

A JSP tag class

<prefix>.taglib.<RendererName>TagHandler

A Facelets Tag Handler class.

<RendererName>

A JSP/Facelets Tag name

Here is the Java classes structure for the components, that uses JSF events:

Chapter 10. Template tags overview

10.1. <ajax:update>

The <ajax:update> tag allows to update a collection of nodes. By default, Ajax response updates only one node with its children that is marked by id = clientId. If you need to update a number of nodes you should add a comma separated list of ids to <ajax:update> tag.

10.2. <c:if />

The <c:if /> tag is a simple conditional tag, which evaluates its body if the supplied condition is true.

Table 10.1. The <c:if /> attributes

Attribute Name

Description

Required

test

Defines the test condition that determines whether or not the body content should be processed.

True

10.3. <c:object />

The <c:object /> tag declares a variable that is used in Java code with a value returned by an evaluated expression. A type of the result must match to the type defined by the "type" attribute.

Table 10.2. The <c:object /> attributes

Attribute Name

Description

Required

var

Defines a name of the variable

True

value

Defines an expression to be evaluated

True

type

Defines an object type

True

10.4. <c:set />

The <c:set /> tag declares a request scope variable with a value returned by an evaluated expression.

Table 10.3. The <c:set /> attributes

Attribute Name

Description

Required

var

Defines a name of the variable which holds the value

True

value

Defines an expression to be evaluated

True

10.5. <f:attribute />

The <f:attribute /> tag assigns a value to a component attribute.

Table 10.4. The <f:attribute /> attributes

Attribute Name

Description

Required

name

Defines the name of a component attribute

True

value

Defines a value of the attribute

True

10.6. <f:clientid />

The <f:clientid /> tag declares a ﻿variable with a ClientId of the component as the value.

Table 10.5. The <f:clientid /> attributes

Attribute Name

Description

Required

var

Defines a variable name

True

10.7. <c:forEach />

The <c:forEach /> iterates over a collection, iterator or an array of objects. It uses the same syntax as the standard JSTL <c:forEach /> tag.

Table 10.6. The <c:forEach /> attributes

Attribute Name

Description

Required

begin

Defines the starting index

False

end

Defines the ending index

False

items

Defines the expression used to iterate over. This expression could resolve to an Iterator, Collection, Map, Array, Enumeration or comma separated String.

False

step

Defines the index increment step

False

var

Defines the variable name to export for the item being iterated over

True

10.8. <f:call />

The <f:call /> tag calls a method. For example it calls an additional method from the base class.

Table 10.7. The <f:call /> attributes

Attribute Name

Description

Required

name

Defines a name of a method

True

class

Defines a class name

True

10.9. <f:parameter />

The <f:parameter /> tag specifies a parameter value for a method invoking. It is used within <f:call /> tag.

Table 10.8. The <f:parameter /> attributes

Attribute Name

Description

Required

name

Defines a parameter name

True

value

Defines a parameter value

True

10.10. <f:insert />

The <f:insert /> tag calls some subTemplate.

Table 10.9. The <f:insert /> attributes

Attribute Name

Description

Required

name

Defines a template name

True

10.11. <f:resource />

The <f:resource /> tag is responsible for receiving a resource object such as image.

Table 10.10. The <f:resource /> attributes

Attribute Name

Description

Required

name

Defines a resource name which contains a path to the resource

True

var

Defines a resource variable that is used in a template

True

10.12. <f:root />

The <f:root /> tag defines a root element for the renderer template.

Table 10.11. The <f:root /> attributes

Attribute Name

Description

Required

class

Defines a name for the generated class

True

baseclass

Defines a name for a base class for the renderer

True

component

Defines a component name

True

10.13. <h:scripts>

The <h:scripts> tag defines a static resource or class for JavaScript that is added to a page at rendering time.

10.14. <h:styles>

The <h:styles> tag defines a CSS or XCSS resource that is added to a page at rendering time.

10.15. <jsp:declaration />

The <jsp:declaration /> tag declares a Java code that is inserted in a renderer class.

10.16. <jsp:directive.page />

The <jsp:directive.page /> tag allows you to import classes or packages in a renderer class.

Table 10.12. The <jsp:directive.page /> attributes

Attribute Name

Description

Required

extends

Defines a base class for the imported classes

False

import

Defines classes or packages that are imported in a renderer class

True

10.17. <jsp:scriptlet>

The <jsp:scriptlet> tag inserts its content into the main rendering method.

10.18. <u:insertFacet />

The <u:insertFacet /> tag inserts specified facet.

Table 10.13. The <u:insertFacet /> attributes

Attribute Name

Description

Required

name

Defines a name of a facet

True

10.19. <vcp:body />

The <vcp:body /> tag allows to split a template content into parts that are passed to encode() methods and defines when children elements rendering should be invoked:

the template content before the <vcp:body /> tag is inputted into encodeBegin() method

the template content after the <vcp:body /> tag is inputted into encodeEnd() method