As mentioned in my talks at JavaOne San Francisco 2012, JSF 2.2 will include a new feature I'm calling HTML(5) Friendly Markup. I owe a debt of thanks to Frank Caputo for collaborating with me on ideas and code for the feature, including the code example from this blog entry. The JSR-344 Expert Group also deserves mention. In true lean fashion, this code sample is taken directly from TDD tests in Mojarra, which means you can easily get the source.

First, let me re-state what I think is one of the core value propositions of JSF: UI Components libraries. These libraries give page authors the ability to embed a simple tag in their view, such as < p:calendar>. With that simple act, the page author can trust that when that component gets rendered to the browser, it will actually be "expanded" to a potentially gigantic and complex bunch of HTML/CSS/JavaScript that provides a beautiful and fun-to-use (including ajaxfied) UI experience for choosing a date. Obviously, it's not just dates, but any of the many components offered by any of the many JSF UI Component libraries available.

The use of UI Component libraries is fine in many cases, but if your page-author would rather not have JSF getting in the way of rendering, and would rather have 100% control of the HTML rendering themselves, JSF 2.2 HTML(5) Friendly Markup is the answer. This approach lets the page author shine while letting JSF handle the prosaic task of processing the interaction with the server. For years, I've been calling this the "motherhood and apple pie of web-apps". The ability to write "prue" HTML as your view is one of the things the Wicket camp has been touting for a long time as a key value proposition oftheir framework. Now JSF has it too, but with the all additional features people have grow to enjoy over the years.

Let's jump right in with the HTML code.

Listing 1: JSF 2.2 HTML(5) Friendly Markup and Ajax

  1. < !DOCTYPE html>
  4.     < head jsf:id="head">
  5.         < title>Putting it all together< /title>
  6.         < script jsf:target="body" jsf:name="js.js"/>
  7.         < link jsf:name="css.css" rel="stylesheet" type="text/css" />
  8.     < /head>
  9.     < body jsf:id="body">
  10.         < form jsf:id="form" jsf:prependId="false">
  11.             < label jsf:for="name">Name< /label>
  12.             < input jsf:id="name" type="text" jsf:value="#{complex.name}">
  13.                 < f:ajax execute="@this" render="progress"/>
  14.             < /input>
  15.             < label jsf:for="tel">Tel< /label>
  16.             < input jsf:id="tel" type="tel" jsf:value="#{complex.tel}">
  17.                 < f:ajax execute="@this" render="progress"/>
  18.             < /input>
  19.  
  20.             < label jsf:for="email">Email< /label>
  21.             < input jsf:id="email" type="email" jsf:value="#{complex.email}">
  22.                 < f:ajax execute="@this" render="progress"/>
  23.             < /input>
  24.  
  25.             < label for="progress">Progress< /label>
  26.             < progress jsf:id="progress" max="3">#{complex.progress} of 3< /progress>
  27.  
  28.         < /form>
  29.     < /body>
  30. < /html>
  31.  

Note that this is HTML 5 markup as evidenced by the DOCTYPE on line 1, and the use of the < progress> element on line 26. Next, note the absence of a JSF UI Component Library, such as < http://java.sun.com/jsf/core>,< http://primefaces.org/ui>, or < http://richfaces.org/rich>. Instead we have a smattering of XML namespaced attributes from the new namespace < http://java.sun.com/jsf>. XML namespaced attributes may be new to HTML authors, but they are not new to markup. Just as HTML elements can be supplied by a namespace, it turns out that attributes can be supplied as well. In Listing 1, line 13 is an example of using an element from the < http://java.sun.com/jsf/core> namespace, while every occurrence of the string jsf: (such as line 4) is an example of using an attribute from the < http://java.sun.com/jsf> namespace. One popular benefit of this approach is that you can open up such pages in a browser using a file:/// URL. If you do that with this particular page in Firefox, you'll see this:

Viewing Listing 1 as a file:/// URL in a browser 

Of course, that's not fancy, but the point is that you can write plain HTML, including HTML 5, and style it as you like and view it without having the JSF runtime. On the other hand, when youdo have the JSF runtime, you get the benefits of JSF, such as easy ajaxfication. For example, the standard< f:ajax> tag will cause an ajax update to happen for the "sensible" DOM event for the component in which it is nested. In the case of text fields, that's "blur". Of course, you can customize what DOM event will cause the update, and also customize which elements will participate in the ajax request, but that sort of thing is not interesting in the HTML expert role.

How does this work? If you want to dive deeper, and you certainly do not need to in order to use this feature, you can look at the javadocs for classjavax.faces.view.facelets.TagDecorator. You can browse the latest spec javadocs by following the instructions in this blog entry, or you can download the latest maven -javadoc.jar.

As a parting note, and I can't stress this enough, the javadoc is part of the JSF specification. The intended audience is those implementing JSF,not those using JSF. I depend on the technical authoring community, including the Java EE Tutorial, as well third-party authors(including me) to teach everyone how to best use JSF.

Advertisement

I'm teaching a JSF class on Friday 23 November 2012 in Nuremberg, Germany, just after the always awesome DOAG Conference. Here are the details.

Date: Friday, 23.11.2012, 9-17h (Starting at 8:30)

Place: NewElements GmbH, Thurn-und-Taxis-Str. 10, 90411 Nürnberg

Cost: 299.00 EUR per-person (including lunch and tax)

Technorati Tags: edburns

5 Comments