About this Book

This book is written for people who currently develop Java web applications—architects, application developers, and front-end developers. From my perspective, architects worry about the application's design, which technologies are used, and how the development process will work. Application developers build model objects, application logic, and so on, while front-end developers concentrate on building the GUI, usually with a display technology like Java-Server Pages (JSP) or Velocity. In many shops, these roles are performed by the same people, or those in different roles have overlapping skill sets. JSF is a web application framework like Struts, WebWork, or Tapestry, but this book is accessible even if you haven't used a web framework before.

JavaServer Faces in Action is divided into five parts. The first part covers JSF basics. Chapter 1 explains the motivation behind JSF, examines how it fits into the current landscape, and has the requisite Hello, world! example. This chapter also provides a brief overview of the foundation technologies JSF uses: HTTP, servlets, portlets, and display technologies like JSP. Chapter 2 delves further into JSF by examining its core concepts and explaining in detail how JSF performs its magic. Chapter 3 covers everyday topics like configuration, JSP integration, JavaBean initialization, and navigation. Chapters 4 and 5 cover the standard UI components, and chapter 6 examines internationalization, validation, and type conversion. All of these chapters explain JSF as a technology, but also reveal how it is used within tools.

Part 2 is focused on building a UI using all of the concepts outlined in part 1. It begins with chapter 7, which introduces the case study that is used throughout parts 2 and 3. Chapters 8, 9, and 10 build a working prototype of the case study using UI components and JSP without any Java code.

Part 3 focuses on the application code required to turn the prototype into a real application. Chapter 11 outlines JSF's Java API from an application developer's perspective, while chapters 12 and 13 walk through design and development of the application. Chapter 14 examines integration with existing frameworks like Struts.

Part 4 looks at the other side of the coin: extending JSF with UI components, renders, validators, and converters. Chapter 15 examines the JSF API from a component developer's perspective. The print edition ends with appendix A, which looks at using JSF without JSP.

Following appendix A is an online extension (part 5) which is downloadable at no charge from www.manning.com/mann. The online extension is chockfull of examples that build upon the foundation laid in part 4. Chapter 16 shows how to develop a basic UI component, and chapter 17 examines renderers. Chapters 18 and 19 show how to build more sophisticated UI components, and chapter 20 walks through developing a validator and a converter. All of these chapters use examples that are applicable to everyday web development.

The online extension ends with four appendices that cover a range of additional topics. Appendix B provides thorough coverage of JSF support in Oracle JDeveloper, IBM WebSphere Studio, and Sun Java Studio Creator. Appendix C looks more closely at JSF's architecture and shows how to extend it with pluggable classes. The last two appendices are references: appendix D covers every configuration element, and appendix E lists time zone, language, and country codes.

How to use this book

This book is part tutorial, part case study, and part reference. It's written so that it can be read sequentially, but I have tried to ensure that individual sections make some sense in isolation. That being said, if you have the time, just start from the beginning and skip the sections that don't seem relevant. Be careful skipping entire chapters, because each chapter may have a nugget of information that you find useful.

Of course, few people believe that they have any time (let alone the time), so here are a few guidelines. If you're an architect, you should peruse most of this book, but pay close attention to chapters 1, 2, 3, 6, 8, 12, 13, and 15. You may also want to peruse appendix A, and online extension appendices B and C.

Application developers should read most of parts 1–3, but you can skim chapters 4 and 5. You only need to read chapter 14 if you're working with an existing web application, or if you're currently using Struts. Advanced developers should certainly read parts 4 and 5 (online), as well as appendix A, and online extension appendices B and C.

Front-end developers should read all of parts 1 and 2, with the possible exception of parts of chapter 2. In general, this book becomes more complicated as you get closer to the end.

References

References to web sites, books, and articles are denoted in brackets ([]) and can be found in the References section at the end of this book. For example, the author's community site, JSF Central [JSF Central] is a great place to find out more information about JSF news, products, and resources. In the References section, the bracketed text maps to the actual URL:

[JSF Central] JSF Central community web site, http://www.jsfcentral.com.

The bracketed name looks the same regardless of whether it's a web site, a product, a book, or an article.

Conventions

Like in any good book, this text is mostly self-explanatory. I do, however, use a few conventions, which are explained in the following sections.

Boldface type

I use boldface type to emphasize portions of code segments (which could be in Java, XML, or JSP). Usually I'm trying to point out the meat of the code or draw attention to text that was added to a previous listing.

Italicized type

Italics are used when I'm defining a word. I also use them to emphasize particular words, in the usual way.

Courier type

Courier type (like this) is used for code (Java, XML, or JSP). I use it in code listings, but also for Java class names, XML tags, and anything else you might type into a development tool.

Component tables

In chapters 4 and 5, I use specialized tables to describe JSF UI components. The first is a Component Summary table; here's an ex

HtmlOutputText summary
Component HtmlOutputText
Family javax.faces.Output
Possible IDE Display Names Output Text
Display Behavior Converts the value to a string and displays it with optional support CSS styles. (If the id or style property is set, encloses the text in a element.)
Tag Tibrary HTML
JSP Tag <h:outputText>
Pass-Through Properties style, title
Common Properties id, value, rendered, converter, styleClass, binding (see table 4.2)
Property Type Default Value Required Description
escape boolean true No Controls whether or not HTML or XML characters are escaped (displayed literally in a browser).

Don?t worry about what this means quite yet—the point is that all of the standard JSF UI components are described this way. The idea is to give you all of the basic details about the component in one single table.

UI component examples are handled in tables as follows:

HtmlOutputText example: Text is escaped by default.
HTML What are &lt;i&gt;you&lt;/i&gt; looking at?
Component Tag <h:outputText value="What are <i>you</i> looking at?"/>
Browser Display

Here, I show the HTML output, the JSP component tag, and the browser display, all in one table. This way, you can easily see how the three different pieces are related. The HTML is displayed first for those who think in terms of HTML.

Code annotations

I use code annotations because they look much cooler than comments. Here?s an example:

public String myAction()

{

// Do something

}

Sometimes I?ll expand upon annotations in paragraphs after the code listing, using numbered cueballs like this: .

Callouts

I use the typical callouts like NOTE, WARNING, DEFINITION, and so on throughout the text to emphasize specific points that may otherwise get buried in ordinary text. Here?s an example:

DEFINITION

A UI component, or control, is a component that provides specific functionality for interacting with an end user. Classic examples include toolbars, buttons, panels, and calendars.

In addition, I use a couple of unique ones:

BY THE WAY

Makes a point that isn?t essential to the current text, but may be useful anyway. Usually, I?m attempting to address related questions you may have.

SOAPBOX

My own personal opinion. Take these with a grain of salt.