HTML and CSS Reference
In-Depth Information
Chapter 6
Going Deep: JSF Custom Components
Up till now we have looked at Java Server Faces from the page author's and application developer's point of view. Page
authors are concerned with authoring the user interface, which is about building the markup, scripts, and styles in
Facelet views where JSF components are utilized to introduce dynamic content and behavior. Application developers
are concerned with writing the server-side behavior of an application. That includes building managed JSF beans
used directly by the page author's Facelet views as well as Enterprise Java Beans (EJBs) containing business logic and
mechanisms for persistence such as JPA entities.
In chapters 6, 7, and 8 we will focus on the responsibilities of component writers. The role of a component writer
is to create libraries of reusable components that either support a specific application or can be reused across multiple
applications. Chapters 7 and 8 demonstrate the development of composite components. The rest of this chapter will focus
on how to create non-composite components. Chapter 9 introduces two popular libraries with reusable general-purpose
components. These libraries are ready to use by page authors and application developers and do not require a component
writer. This chapter introduces the JSF component model and how to implement custom reusable components. Before
we plunge into the JSF component model we will first look at some characteristics of component-oriented software
development. When developing components the focus is on creating a software package that has a single well-defined
responsibility. The package should have minimal interdependencies to ensure low coupling between the component and
the environment in which the component is used. With single responsibility and low coupling it is possible to implement
thorough unit tests that cover many if not all aspects of the component. It also offers an opportunity to fully document both
how to use the component and how it was designed. Lastly, when developing components, the component writer must take
into consideration that the component may be used in unforeseen scenarios. This is one of the major differences between
application and component development. In application development there is full control of the application and features
provided to the user. You can easily get away with writing an application where there is high coupling and low cohesion
between objects. When writing a component the scope is limited by having a single responsibility and well-defined
interfaces with the outside world. This allows for low coupling and high cohesion.
In other words, when you create a component you must not make any assumptions about the outside
environment and it must have a well-defined interface for inputs and outputs so that the outside environment should
not consider how a component is implemented but simply rely on the contract exposed by the component.
We will consider two types of custom components: user interface (UI) components, which are visual in their
representation to the user, and non-user interface (non-UI) components, which implement nonfunctional or
developer requirements.
Understanding the JSF Component Architecture
JSF was developed to solve practical problems arising during the development of web applications. Among the
problems solved by JSF is the support for reusable components that encapsulates the actual implementation from
page authors. JSF comes with a set of standard components but those are rarely enough when you embark on building
anything but a simple web application. Before you start developing custom components you must understand the JSF
component architecture and how it was intended to be used by component writers.
Search WWH ::

Custom Search