The h:select* Elements

There are seven JSF HTML tags to render selections. To show how they differ from each other, I created in Eclipse the small project testf. You will find it in the testf project subfolder of the software package for this chapter. If you import testf.war in Eclipse, you will be able to try it out by typing http://localhost:8080/testf/ in your web browser. Figure 8-5 shows you what you will see in your browser after selecting values in the controls (and hitting the Submit button , although it is not necessary to do so).

I have highlighted in bold the selection components. h:selectBooleanCheckbox renders a single checkbox; h:selectManyCheckbox, h:selectManyListbox, and h:selectManyMenu render multiple selections; and h:selectOneListbox, h:selectOneMenu, and h:selectOneRadio render single selections.

The tags wire to each HTML control a different property of the managed bean. Notice the use of the core JSF tags f:selectItem and f:selectItems to provide the information needed for the options of the HTML select elements.

From this example, you can also see how to use h:panelGrid and h:panelGroup to render an HTML table. Differently from HTML, where you need to identify rows with tr elements and cells within rows with td elements, with h:panelGrid you specify at the beginning the number of columns, and all the components between its begin and end tags “flow” from left to right into the table. If you need more than one component within the same cell, you group them together with h:panelGroup.

There isn’t really much to explain. JSF takes care of executing the initialization method of the bean, which initializes three values to be provided for selection through the select attribute and sets up the arrays needed to save the user’s choices.

Ajax

I introduced JavaScript in the previous chapter: Asynchronous JavaScript and XML (Ajax) is a mechanism for letting JavaScript communicate with the server asynchronously, that is, without reloading the page. This is possible by means of the JavaScript built in object XMLHttpRequest.

You’ll perhaps see some other time zone, but the format will be identical. A good place to check out the abbreviation for your time zone is www.timeanddate.com/time/zones/.

As you can see, I’ve highlighted two lines. The first is where you load the file ajax.js, which contains the JavaScript code to support the Ajax operation. The second line is where you execute the ajaxFun JavaScript function whenever you click the Update button. Notice that you pass to ajaxFun the names of the form and of the input element to be updated. You could have hard-coded the string "tForm.tElement" within JavaScript, but it would have been bad programming practice to use within ajax.js identifiers defined elsewhere. Global variables invariably lead to code that’s a nightmare to maintain and should be avoided whenever possible.

To complete this brief introduction to Ajax, I still need to show you the JavaScript code. However, before I do that, check out Figure 8-6 to see how the browser renders the page. To test the application, import the ajax project from the software package for this chapter into Eclipse. Then, type in your browser http://localhost:8080/ajax/.

First, you instantiate an object of type XMLHttpRequest.

When ajaxReq “holds” an object of the correct type, you set up the HTML request method (e.g., GET) and the target URL (in this case, the JSP module time.jsp). At this point, you can send off the request.

I’ve taken a minimalist approach for this example. The idea is for your server to send back an XML document, which you can then parse on the client side.

As you can see, it is almost empty. I have only added a couple of welcome-file elements so that Tomcat tries index.html (which is the default) only if index.xhtml is not there.

Now that you know how Ajax works without JSF, let’s see how to use f:ajax to achieve the same result.

f:ajax

Using f:ajax instead of the mechanism I described in the previous section has several advantages, the most important of which, in my opinion, is that you no longer need to write code in JavaScript, which adds another flavor of Java to the mix. Further, f:ajax is fully integrated with the other JSF libraries.

Figure 8-4 showed the six phases of the JSF life cycle. With f:ajax you can selectively execute components on the server by processing them through the first five phases or render them by passing them through the last phase. You ajaxify a component by enclosing it within the body of f:ajax or by passing to f:ajax the component id.

To convert the Ajax example of the previous section to JSF’s Ajax, let’s start from ajaxf.xhtml, shown in Listing 8-17. The interesting bits are those highlighted in bold.

of second.jsp (Listing 8-2) that you encountered at the very beginning of this chapter.

But this time, I have added to h:outputText the setting of the id attribute. This is because we need to pass it to f:ajax, in the second group of highlighted lines.

The h:commandButton element , contrary to what you saw in previous examples, doesn’t transfer control to another page. Its purpose is only to create an event that triggers f:ajax. Accordingly, the action attribute is not there, and if you look at the WEB-INF folder of the application, you will see that no faces-config.xml to handle navigation is present.

Every time the user clicks the Update button, f:ajax sends a request to the server to obtain the value of serverTimeBean.when, which then the h:outputText element with id timeField displays. You don’t need to write JavaScript because JSF automatically generates the little script that sends the Ajax request.

The code is almost identical to that of AString.java (Listing 8-8), the major differences being that it has an initialization method and, obviously, generates a string with the current server time. In the software package, you will also find the files that complete the application, index.jsp and web.xml, but they are very similar to the equivalent files you already encountered with other applications.

With this setting, you ajaxify all components of the form. As a result, when you click the Update button, JSF sends an Ajax request, as it did before, and because the render attribute is set to @form, serverTimeBean.when is updated, as before. Events applicable to whole forms are click, dblclick, keydown, keypress, keyup, mousedown, mousemove, mouseout, mouseover, and mouseup.

The resulting page is shown in Figure 8-7.

As long as you remain within the input field, nothing happens. When you hit enter or click outside it, Ajax sends a request to the server to update the property specified in h:inputText. In the example, it sends a request to set serverTimeBean.when to “Tue Apr 28 020”. JSF does it in the Update Model Value phase. Then, during Render Response, Tomcat prepares the Javax response with two values obtained from serverTimeBean.when, one for h:outputText and one for h:inputText. As ServerTime.java always produces a fresh time string, that’s what is returned to the browser, and what you typed in the input field remains unused in the bean’s variable when.

Possible events for input fields are blur, change, click, dblclick, focus, keydown, keypress, keyup, mousedown, mousemove, mouseout, mouseover, mouseup, select, and valueChange. The default is valueChange.

The value of the render attribute can be a single identifier, a space-delimited list of identifiers, or one of the special strings @all, @this, @form, and @none.

The templ Application

In this section, I will describe templ , an application that uses facelet templating.

To create it, I started from the example simplefx I explained in this chapter. You will recall that it essentially consisted of two JSP documents that invoked each other: first.jspx asked you to type something into a text field, and second.jspx displayed what you had typed.

To make an example of templating, I added a third page almost identical to the second one, so that I could show you how to define a template for them. To get started, let’s look at how the first two pages appear in a web browser (Figures 8-8 and 8-9).

Notice that the header of the second page is gray instead of black. The third page is identical to the second one, but its title is “Third page” and the text before the button starts with “Page 3”. To try it out, import in Eclipse the project templ from the software package for this chapter, and then type in a browser http://localhost:8080/templ/.

First of all, notice that I renamed the file first.xhtml. This is because facelet elements (i.e., those with prefix ui) only work inside h:body. This means that you can no longer use the HTML body tag. As h:body requires the extension of the document to be xhtml, I had to ditch the extension jspx. The same applies to first.xhtml, which remains a valid JSP document despite the change of name.

Another difference from first.jspx is that I moved the namespace declarations for the core and HTML JSF libraries from jsp:root to the html tag and then added to them the declaration for the JSF facelet library. As none of the JSF tags are used outside the html element, it makes sense to keep them there, which is where they normally are in XHTML documents.

Finally, notice that first.xhtml includes a standard header with ui:include.

Notice that there is no h:head element in page2.xhtml. This is because JSF, when it encounters a ui:composition element, it ignores everything other than the content of h:body. You got it right: JSF only looks at the lines I have highlighted in Listing 8-22.

Obviously, you cannot remove the JSP header elements and jsp:root when you use JSP code inside h:body. But you can use JSTL and your own custom-tag libraries without declaring the jsp namespace, as long as you declare the appropriate namespaces in the html tag. What you certainly cannot use in any case, with or without JSP declaration, are JSP scripting and directive elements, because anything enclosed between <% and %> is not valid XML.

Let’s go back to describing how JSF handles the pages that make use of templates.

The presence of the ui:composition element with a defined template attribute means that it is the template document that generates the page to be sent back to the user as a response, not the page that contains the ui:composition element.

The two highlighted lines identify two places where the template expects the “client” pages to insert content. If you go back to page2.xhtml and page3.xhtml (Listings 8-22 and 8-23), you will see that the two ui:defines inside ui:composition have the same name attributes as the two ui:inserts of the template.

When layout.xhtml is used to generate the response to a request sent to page2.xhtml, the element <ui:insert name="title">Default Title</ui:insert> is replaced with the string “Second page” and the element <ui:insert name="pageNum"/> is replaced with “2”. For page3.xhtml, the string is “Third page” and the page number is “3”. Notice that the body of ui:insert is the default value for that insert, to be used when the “client” page doesn’t define any value.

In header.xhtml, the element ui:composition doesn’t define a template attribute. Its presence ensures that the rest of the page is ignored when header.xhtml is included with ui:include. Actually, the only line needed in header.xhtml is the one I have highlighted. But the advantage of having a well-formed XHTML page is that you can view it in a browser. With more complex pages, it is sometimes useful to be able to do so.

There is still something I need to clarify. Have you noticed that the header shown in the first page (see Figure 8-8) is black, while the header of the second page (see Figure 8-9) is gray?

loads a style sheet that defines the color of headers to be gray.

Still on the subject of linking to the style sheet with h:outputStylesheet: notice that the name of the resources folder doesn’t appear anywhere. This means that it is hard-coded within the component and that you are stuck with it. But the folder names templates and defaults are entirely my choice. Therefore, you can choose the names you like.

Some Examples

Not surprisingly, for such a trivial component, the code is also trivial. But it tells you a lot about developing components with the composite library.

First of all, inside h:body, you find two elements, a composite:interface and a composite:implementation. Inside the former, you define the attribute named x, and inside the latter, you define the logic of the component.

To access the attribute from within the implementation, you use the expression #{cc.attrs.x).

Listing 8-29 shows you how to use the new component, and Figure 8-10 shows how the page appears in a browser.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"

    >

<html xmlns:="http://www.w3.org/1999/xhtml"

      xmlns:h="http://java.sun.com/jsf/html"

      xmlns:gz="http://java.sun.com/jsf/composite/gz"

      >

<h:head><title>Example of a composite component</title></h:head>

<h:body>

  <gz:hello x="wherever you are"/>

  </h:body>

</html>

Listing 8-29

comp.xhtml

Have you noticed anything unusual in comp.xhtml ? Instead of separately declaring the namespaces of the JSF composite library and of your custom components, you declare a single namespace composite/gz. For this to work, you need to create in the root of your application a folder named resources; create a folder (in the example, named gz) inside resources; and place your custom components there. The name of the component (e.g., hello) is obtained from the name of the component file (e.g., hello.xhtml) by removing its extension.

It is an established practice to use the same string for the prefix and for naming the folder inside resources, and I recommend that you follow it, but the two strings can be different.

It simply means that your new component will not have any attribute to set.

you will see the page shown in Figure 8-11, but be aware that this is not a working page. It’s just to show you how to use composite:attribute .

As it was in the previous examples, you use the expression #{cc.attrs.act} to access from the implementation the value of the act attribute declared in interface. In addition, unlike what happened in the previous examples, you also need a reference in the opposite direction, from interface to implementation. This is because JSF must be able to wire the method set in gz:flip to the h:commandButton component for which the method is meant. In fact, if there were more components in implementation, you could wire the same method to several of them by writing their identifiers in the targets attribute separated by spaces (this is why the name of the attribute is targets, plural, instead of target).

The element composite:actionSource exposes the h:commandButton component, and f:actionListener wires to it the appropriate action listener. Notice that the attribute actionListener has disappeared from h:commandButton.

JSF will take the body of the facet element defined in the using page and insert it where you invoke composite:renderFacet. If you like to insert those components as a facet, you need to use composite:insertFacet instead.