HTML and CSS Reference
In-Depth Information
Unlike the application developer, the page author is focused on developing a pleasing and effective user experience
for the application. JSF's component architecture abstracts away a significant amount of complexity, allowing the page
author to be productive even if they have little familiarity with programming languages such as Java and C#.
The component writer is responsible for developing reusable JSF components that can be used by the page author.
Reusable JSF components can be collected into “component libraries.” Think of this as a palette of components that are
easy to discover, customize, and integrate into your applications. Component libraries are a big contributing factor to
force-multiplying productivity across large developer teams. Two popular and comprehensive JSF component libraries
are PrimeFaces and RichFaces.
Reusable JSF components should support the following capabilities:
•
Encoding:
converting the internal component's properties and attributes into suitable markup
in the pages that use the component (such as HTML).
•
Decoding
: converting incoming requests with related headers and parameters into related
properties and attributes of the component.
•
Adding to this, the component should support request-time events, validation, conversion,
and statefulness. Conversion is the process of converting an incoming request to a suitable
form for the component. Statefulness means that the component must retain its original state
for the new requests. This can be done by saving and restoring the component state across the
different requests.
The application developer is responsible for developing the server-side functionality of the JSF application.
The application developer is focused on developing Java, EJB, or any other language capable of running on the JVM
(Java Virtual Machine). Adding to this, the application developer can define the persistence storage mechanism of the
JSF application (inclusive of the data and the content model) and expose data and business logic objects to be used
from the JSF page.
The tools provider is responsible for developing the tools that help JSF developers to build JSF applications.
These tools include IDE (Integrated Development Environments) plug-ins and extensions and page generators.
The JSF implementor is responsible for providing a standards-compliant runtime or implementation of the JSF
specification for all of the previous roles. Examples of the available implementations of the JSF specification are
Oracle Mojarra (
http://javaserverfaces.java.net/
)
and Apache MyFaces (
http://myfaces.apache.org/
)
.
JSF Evolution: 1.0-2.2
JSF 1.0 was released in March 2004; it represented a significant evolution in the way the web tier was implemented.
But with these advantages also came limitations that needed to be circumvented in order for JSF to gain widespread
adoption in the community. Some of these limitations were related to component performance and others were
related to open defects.
The Expert Group worked hard on the specification and, in May 2004, released version 1.1, which eliminated
some of JSF 1.0's greatest performance issues and had many defect fixes which made the JSF framework usable within
the next-generation web applications. With JSF 1.1, the Expert Group had achieved most of the early goals they set out
to achieve in Java Specification Request (JSR) 127. These goals were related to creation of a standard GUI component
framework that can be supported by development tools that allowed JSF developers to create custom components by
extending base framework components, defining APIs for input validation and conversion, and specifying a model for
GUI localization and internationalization.
■
Note
