JavaServer Faces

Less Code in the User Interface Templates

Java web applications user interfaces have typically been implemented as a set of JSP pages (or pages for similar template-engine technologies, such as Velocity or FreeMarker), where static content (e.g., text and HTML elements for layout) is mixed with elements that generate dynamic content when the page is processed. A problem with this approach is that the pages often end up with logic for maintaining the user interface state—for instance, code for marking checkboxes and list items as selected and for displaying current values in input fields.

When you use JSF with JSP as the presentation layer technology, special elements (JSP custom actions) represent the JSF components. Here’s a snippet of a page with a form showing a user’s food preferences as a set of HTML checkboxes:

    ...
    <h:form>
      <table>
      ...
        <tr>
          <td>Favorite Foods:</td>
          <td>
            <h:selectManyCheckbox value="#{cust.foodSelections}">
                             <f:selectItem itemValue="z" itemLabel="Pizza" />
                             <f:selectItem itemValue="p" itemLabel="Pasta" />
                             <f:selectItem itemValue="c" itemLabel="Chinese" />
                           </h:selectManyCheckbox>
          </td>
        </tr>
        ...
      </table>
    </h:form>
    ...

The details are not important at this stage, but note that there are no loops or conditional tests in the page. This logic is instead encapsulated in the JSF components represented by the <h:selectManyCheckbox> and <f:selectItem> elements. When the form is submitted, the JSF framework saves the list of current selections in an application object ...