In summary: I would recommend buying this reference if you are a consumer, designer, UI-developer who is working with existing component libraries, Facelets or JSF 2.0, and not so much focused on creating custom Java-components of your own. I don’t, for every-day web-site components, see why you would need much more than what is featured between the covers of this book. Ian Hlavats does a fantastic job of making bringing JSF to the everyday development setting.

JSF 1.2 Components By Ian Hlavats Download Chapter 2: Facelets Components as a PDF

In detail:

Initially hesitant to buy a reference on components, I have to admit that I was surprised to learn so much by reading through this book. As a member of the JavaServer Faces 2.0 expert group, and a full-time software engineer, components are not my strong-suit. If you’re at all like me, then you’re probably asking yourself the same question I did:

“What can I learn in this book that I can’t find on Google? JavaServer Faces has a huge online community, and there’s a lot of information available already.”

It’s a valid question, but you should keep reading because this book offers something important that I rarely find in blog entries or wikis: “features you wouldn’t think to look for; features that you wish you’d thought of, or don’t know how to make yourself.” I wish I had found this book when I started using JSF, because I’d probably have been more comfortable, and much more productive with our component side of the life-cycle, so to speak; I discovered features of the framework, and pre-made UI-tools that I wish I’d known about years ago.

Things you’ll learn about:

Modal windows, menus, wizards and workflows, AJAX anything with Ajax4JSF, i18n and localization, gCal-like schedules with Apache Tomahawk, multi-field validation, calendars, charts and graphs, file-uploads, user permissions/security, skinning, styling, and all major component libraries are covered in this book (save PrimeFaces, which gets a mere mention.)

If you think you’re looking at “Just another book on JSF component writing,” that’s not entirely the case. This book provides real solutions, real examples on how to get started writing JSF applications using existing component libraries and plug-ins. There are two types of chapters in this book: tutorials and references. The tutorials will get you up and running with a quick example, while the reference sections go in depth on usage of individual components within each library.

You’ll also (as a bonus, in my opinion) get some appetite-whetting information on the JBoss Seam framework, which is a user-friendly and business-oriented extension to the Java EE technologies. I didn’t get a very good picture of all of the concepts until I actually looked at the code samples (downloadable here, or just follow the link in the preface,) but that’s hardly a strong criticism; though, it may have helped if the code samples were more explicitly, frequently referenced.

In the end “The title doesn’t lie”:

• I haven’t seen a more comprehensive book on component libraries and component writing made available to date.
• JSF2 component writing has been simplified, but if you want to supplement your app with everyday things like in-place editing, accordions, and more, you’re going to want good examples; this book provides examples in abundance (even examples of JSF2 EzComp, which is a dream to use. UI like it was meant to be)
• Even if components and UI design are not your strong-point, that is exactly why you should read this book; it makes component-based design easy to understand, and easy to implement.

The author covers many of the advancements in component writing and simplified configuration that are provided by JSF 2.0, but I would have liked to hear some information on the component behaviors model, and mention of integration with frameworks like CDI (JSR-299) and Spring; however, this is not entirely relevant to component writing, and plenty of information exists on sites like www.javaserverfaces.org or Google.

My one complaint is that for a book titled “JSF 1.2 Components,” it did not explain, or teach me how to create custom Java-based components, which are essential for complex behavior and interaction at some level. JSF 2.0 has done a good job of making Java-based components unnecessary, but this book is titled JSF 1.2 components, thus, I would have liked to see how to write a Java-based component in JSF 1.2.

End notes:

Make sure you check out www.javaserverfaces.org. It’s a great starting point and reference for JSF that you will undoubtably bookmark if doing a lot of work, and doing the work with this book. Also check out http://ocpsoft.com/prettyfaces/ for more information on Pretty URLs in JSF, and building client-facing JSF web applications.

Version 1.2.3_GA: binary, source, documentation (stable)
Minor Release: 20090415

1. Added optional <action onPostback=”false”> boolean flag to prevent action methods from being called on form postback. Defaults to true;
2. Added optional <query-param decode=”false”> to prevent java.net.URLDecode.decode() from being called on a specific managed query-parameter. Defaults to true;
3. Added unit tests for several critical classes.
4. Minor to moderate refactoring of PrettyFilter/PrettyContext

Version 1.2.3_RC2: binary, source, documentation (stable)
Minor Release: 20090331

1. Servlet forwards are working

Version 1.2.3_RC1: binary, source, documentation (stable)
Minor Release: 20090319

1. Managed query-params now accept multiple parameters of the same name: E.g.: String[] names — would accept a list of parameters (with the same name) from the request
2. Enhanced configuration loading — PrettyFaces now looks for /META-INF/pretty-config.xml by default, in addition to accepting a comma-separated list of user config-files in the web.xml init param: com.ocpsoft.pretty.CONFIG_FILES — submitted by Aleksei Valikov
3. JSP support for standard attributes on the pretty:link tag has been fixed. The pretty link will now accept style=’mystyle’ and other attributes — from Derek Hollis at OcpSoft

“The community was speaking, but until recently, nobody was listening.”

A lot has changed since May 15, 2001, when the first ballot review of the JSF 1.0 framework was just beginning. To this day, Sun’s flagship web-application framwork has been an uncompromising box of tricks and gotchas, with little community adoption. This has been mostly due to its relatively developer-unfriendly nature; however, the second phase is coming, and with JSF2.0 peeking out from the edge of its nest, a new life is beginning to show.

From the start, JSF had mixed support from the community, with opposition from major players like IBM, HP, and the Apache Foundation. Apache voiced strong concerns because of “Sun’s current position that JSRs may not be independently implemented under an open source license.” In addition, they saw, “little value in recreating a technology [Struts] in a closed environment that is already available in an open environment.”¹

Apache’s concerns drew several other players to vote against JSF, but the final vote still passed with a 10-5 margin (Accenture abstained from voting.) With the voting complete a short two weeks later, the first JSF expert group was formed.

Three months after the formation of the expert group, the first JCP community review was complete, and Sun’s new star web-framework was on its way to reality. On the side of the box was a label, which read, “Final release, May 2004: Warranty Void if Removed” It was done, and their hands were off.

But some things that should not have been forgotten, were lost.

Since JSF was engineered by companies like IBM and Oracle, major contractors in the industry, most of the emphasis was placed on creating a modular architecture that could be ‘easily extended’ and broken down into components. While technically sound, and well designed for large companies where developers are part of an assembly line, the community at large found JSF hard to use.

JSF lacked life-cycle extension; there are six defined phases, and if you need to add another one, you’re out of luck. Also lacking was easy component creation — Creating a component in JSF today requires modification of no fewer than four separate files, even more if you use a separate renderer class. You were on your own if you wanted to validate multiple form fields against each other.

Navigation rules were ungainly, and difficult to follow logically without a visual editor. Community documentation was almost a joke. Sun’s mailing list and forum are still the best places to find help. There are some very knowledgeable people, but nowhere to be found is what most developers find most useful: a central, persistent resource for documentation. I like PHP’s model – official documentation with community feedback in comments below.

The lack of bookmarking support is one of the most highly-criticised facets of JSF, which is where I got involved, leading me to create the PrettyFaces URL rewriting extension. If you need to be convinced of the collective dysfunction on this topic, look at the results of a google search for “jsf bookmark”. Yet, at the root of all this was something JSF lacked until very recently – something very important.

A set of ears.

The community was speaking, but until recently, nobody was listening. Blame JCP? Cay Horstmann thinks that the JCP needs to be more open to the community.²

Personally, I’m surprised that JSF wasn’t abandoned completely, which says in my mind, “they got something right.” The framework does a lot for you, but “I can’t figure out how to use it”, “it doesn’t do what I need,” and “everything takes forever.”. This is where we see the light, and JSF2 enters from stage left; a new star performer?

From the very start, JSF2 is different, more open. Ed Burns, Ryan Lubke, Jim Driskoll and other blogging developers can be thanked for engaging the community in a way that Sun has not done before.

Convention over configuration has taught us a lot. We might thank Ruby on Rails, or possibly a collective laziness, but the JSR314 Expert Group has taken it to heart. “EzComp” is JSF’s new component writing system, and yes, it’s “Ez”.

Jim Driscoll explains how to create a “click to edit” AJAX input field, like those so popularly seen on Flickr, or Facebook. (About 30 lines of XHTML, plus JavaScript.) Tag libraries no longer need to be defined manually; they will spring to life as needed, based on the names and interfaces of your components.

JSF2 is showing stunning promise and vision. This is just a small set of changes that will drastically improve the usefulness and adoption of JSF. When a rookie Java web-developer can pick up JSF2.0, in their IDE of choice, and write a small, useful application in a day, that’s when we’ll know they’ve gotten it right. Man, life is good… but.

Where are my bookmarks?

Ahh yes.

After learning about JSF2 in mid-October, I’ve been following very closely the changes and discussions around its new architecture, and how it can be ‘fixed.’ At the top of the wish list, among other contenders like “Fixing Navigation Rules,” and even above “Simplified component development,” is one very near to my heart: “Enhanced support for GET requests.”

I began work on PrettyFaces before learning that JSF2 was in progress, but not before I had evaluated the other options available from the community. Jboss Seam had a UrlRewriting feature, but I found it cumbersome, requiring too much configuration, and the added burden of learning the entire Seam framework was too much for me. RestFaces was an alternative that I tried for a while, but several design choices made it difficult to incorporate in a non-invasive way, and I was left writing lines and lines of code in order to compensate for its (albeit few) shortcomings.

Shocked, disappointment struck when I was contacted by a PrettyFaces user, disheartened, who urged me to contact the JSF2 expert group because they were close to abandoning bookmarking support for the next release, a full five years after the last specification update. How could they be considering omitting such a critical feature? It would surely finish off whatever damage had been done by the first 8 years of JSF’s mis-managed life, and it would be dead forever. “Long live Struts,” Apache would tout.

New life.

But fate struck, and before I could even begin to write emails, begging for reconsideration, I got another pop-up from my inbox.

From: Dan J. Allen – Jan 10, 2:50pm

Lincoln,

Hey there. I have recently joined the JSF EG by way of my employment with Red Hat. My first action was to submit a couple of proposals to make JSF more "website friendly". After all, that is what got me interested in Seam in the first place.

In the most recent proposal, I cited the statements you made in a recent blog post. I have attached that proposal to this e-mail as well as a related proposal. We are listening (at least those of us at Red Hat) and we are trying our best to improve JSF within the boundaries that we have to work (i.e., the JCP). The JSF EG was definitely dysfunctional in the past, but Ed Burns, Red Hat, and a handful of other members have really started to turn things around. Adding pretty URLs is definitely too big of a change at this point given the time constraints, but you may find these two proposals to satisfy many of your other concerns. Feel free to provide feedback to the JSF EG regarding the design changes.

-Dan

Dan is the author of Seam in Action, and from my interactions with him, a brilliant individual. If he isn’t rich already, in heart or on paper, he will be someday.

Struck by two emails on this subject in the same day, I “hurriedly” (from 11pm-2am) typed a response. Someone at RedHat was asking me for my feedback? Talk about an ego trip. My friends at work won’t let me hear the end of it.

The proposal was stunning. While still omitting Pretty URL rewriting, it contained in depth solutions for using query-string parameters (http://url?key=value) to bookmark pages within JSF. It lacked page-load actions, but that would follow, as we talked through the issues, in the next few days.

During the process of reviewing Dan’s proposals, providing feedback where I could, and wishing I weren’t just a part-time contributor, we worked through issues regarding usability, convention over configuration, and strategies for implementing the new functionality that would be required. Two weeks and 91 emails later, we had a draft of the spec, and off it went (via Pete Muir at RedHat) to the Expert Group for review.

The proposal was accepted; Dan’s job got even better. Within a week, he would have to implement his proposed specification, create a sample application, make any necessary changes to the spec, submit it back to the EG, and believe me, it was good.

Things yet to come.

JSF2 is still under review, and all of these changes may yet be changed, but I’m confident that the people in charge have heads on their shoulders, and that they are pointing in the right direction.

I’m impressed. Impressed by Dan Allen, Jim Driscoll, Ryan Lubke, and by Sun for starting to recognize that its developer community is its best chance at survival. JSF2 won’t have everything that we’ve asked for, but it will have the most critical features that the community has asked for. I’m impressed that it’s turning out so well: Component writing is truly easy; pages will be bookmark-able; templating is built in; and annotations are on the way to deprecating faces-config.xml for trivial tasks.

So what can Sun do next? Well. For starters, keep listening. Don’t limit ideas to people on its payroll. JSF2 will be a success if Sun gives users a voice.

The developer blogs are great, but we need a centralized place for core documentation. The site needs to be fast, and you should be able to easily register and contribute. Yes, it will take management and oversight, but we aren’t out to hurt anyone. Dear sun: “We like what you’re doing, and the direction in which we think you might be turning. We’re here to further the cause of software development, and guess what… If you listen to us… we’ll do it for free.”

Whether or not this happens, the future of JSF is in our hands.

–

1http://www.jcp.org/en/jsr/results?id=614

2http://weblogs.java.net/blog/cayhorstmann/archive/2009/01/a_call_to_fix_t.html

• Enhanced internal navigation/redirects. Returning “pretty:” from a JSF action method, or Pretty action method will cause a redirect to the current page. Effectively a refresh.
• Added the <pretty:link> component.
• Added attribute to Pretty action method configuration, allowing targeting of action methods to specific JSF phases in the lifecycle.

View the documentation here, for PrettyFaces.

—-

PrettyFaces is an OpenSource JSF extension which enables creation of bookmarkable, pretty URLs made easy. Our goal was to solve this problem as simply as possible, while still enabling a useful set of functions such as: page-load actions, integration with faces navigation, dynamic view-id assignment, and managed parameter parsing. All of this without introducing unnecessary coupling.

(View this issue on the JBoss tracker here. Keep reading, there is a fix… download fix)

The issue:

When using the a4j:form component, the data=”#{managedBean.property}” the properties defined in the data element list are supposed to be available after the a4j event in the data JavaScript variable; however, with <a4j:form> the attribute is not correctly causing the JavaScript data variable to be populated.

The data variable is always undefined, even if the managed bean property is set to a valid value. This is exhibited by the alert box as the value is displayed, “(undefined)”.

Example:

—-

The workaround:

Taking a look at the source code revealed that the <a4j:form> was not in fact including this behavior at all in the broadcast() method, which is where the data element processing occurs in the <a4j:commandButton>.

UIAjaxForm.broadcast()

    /* (non-Javadoc)
     * @see javax.faces.component.UIComponentBase#broadcast(javax.faces.event.FacesEvent)
     */
     public void broadcast(FacesEvent event)
               throws AbortProcessingException {
          // perform default
          super .broadcast(event);
          if (event instanceof  AjaxEvent) {
               // complete re-Render fields. AjaxEvent deliver before render response.
               setupReRender();
          }
     }

—-

In fact, however, if we modify the <a4j:form> broadcast() method to behave like its <a4j:commandButton> relative, we can still achieve this functionality!

Updated: UIAjaxForm.broadcast()

    public void broadcast(final FacesEvent event) throws AbortProcessingException
    {
        super.broadcast(event);
        if (event instanceof AjaxEvent)
        {
            this.setupReRender();
            Object data = this.getData();
            AjaxContext ajaxContext = AjaxContext.getCurrentInstance(context);
            if (null != data)
            {
                ajaxContext.setResponseData(data);
            }
            String focus = this.getFocus();
            if (null != focus)
            {
                UIComponent focusComponent = RendererUtils.getInstance().findComponentFor(this, focus);
                if (null != focusComponent)
                {
                    focus = focusComponent.getClientId(context);
                }
                ajaxContext.getResponseDataMap().put(AjaxActionComponent.FOCUS_DATA_ID, focus);
            }
            ajaxContext.setOncomplete(this.getOncomplete());
        }
    }

—-

We’re set!

I don’t particularly like to repeat this code, so I may get around to refactoring everything and submitting it back to the Ajax4JSF project. For now, though, this blog will have to do.

I believe other functionality that was also broken included both the focus=”elementId” and the oncomplete=”javascriptCode”.

As always, please feel free to improve and comment on this. Enjoy!