Java Reference
In-Depth Information
Building the view
Once we have coded the server side of our example, creating the frontend will be
quite easy, as we made all our resources available through CDI Beans.
One notable difference between the earlier edition of this topic is that
Facelets
are
now the preferred view technology for JSF. Earlier versions of JSF used JSP as their
default view technology. As JSP technology predates JSF, sometimes using JSP
with JSF felt unnatural or created problems. For example, the lifecycle of JSPs is dif-
ferent from the lifecycle of JSF.
Note
Compared to the simpler request-response paradigm on which the JSP lifecycle
is based, the JSF lifecycle is much more complex, since the core of JSF is
the MVC pattern, which has several implications. User actions in JSF-generated
views take place in a client that does not have a permanent connection to the
server. The delivery of user actions or page events is delayed until a new con-
nection is established. The JSF lifecycle must handle this delay between event
and event processing. Also, the JSF lifecycle must ensure that the view is correct
before rendering it and also that, the JSF system includes a phase for validating
inputs and another for updating the model only after all inputs pass validation.
Most of the time Facelets are used to build Java Server Faces views using HTML-
style templates and component trees. Templating is a useful feature available with
Facelets that allows you to create a page that will act as the template for the other
pages in an application (something like Struts tiles). The idea is to obtain portions of
reusable code without repeating the same code on different pages.
So here's the main application structure, which contains a template page named
de-
fault.xhtml
that is referenced by views in the template attribute of the page's
composition
element:
