Part of Infragistics Java product manager Jim Cook's job is to visit with developers at enterprises and help them make better use of his company's NetAdvantage for JSF component suite. Cook has seen many ways developers use JSF in real-world applications, including some of the common mistakes developers make with the technology.

In this interview with Artima, Cook explains the latest features in NetAdvantage, and shares his observations about the challenges developers face when building rich-client applications:

Frank Sommers: How does NetAdvantage help a rich-client developer, and what are the main new features in your latest release?

Jim Cook: Infragistics has designed components for all sorts of platforms. Our JSF offering, NetAdvantage for JSF, is designed to extend the JSF core library in a variety of ways.

While we have all the usual components you’d expect from a component library—input controls, trees, and so on—the jewel of our library is our grid. I don’t think there’s anything you can even compare to our grid in the JSF world: it sports multi-column sorting, is internationalizable, it offers single-cell editing where you can click on a cell and open up an editing field that can be a calendar, a drop-down, or something else. The grid is also easy to use, and it performs very well.

A new feature in our latest edition is a JavaScript eventing model. In the past, the focus of our product was to keep the JavaScript engine under the covers, and to provide only limited access points to it. Our customers had been telling us to open that [event model] up so that they can plug in JavaScript and Ajax calls pretty much anywhere. In response to those requests, we enabled over 200 event attributes across our components.

We divided those calls into a before and after models. Say, you have a hierarchical grid where you can expand a row to show a sub-grid. You can capture an event before the row expands, and another event after the row has expanded. You can gain very fine-grained control over what happens in the component.

Another new feature is the ability to export the entire grid into a CSV format. In prior releases, you could only export a page at a time. Now you can do that with a single click of a button, no matter how large the table is.

We have also renewed our focus around training and helping developers build effective UIs. The Java world has done really well in building up the back-end—things like EJBs and Web services. At the same time, we notice that many developers do not treat the user interface with a similar emphasis. The user interface is often just an afterthought: you have some HTML, some CSS, and some JavaScript, and you’d think that putting all those together is no big deal.

As the Web gets increasingly sophisticated, however, users are expecting a lot more from their Web application interfaces. We’re finding that this trend is pushing more and more Java development effort into the UI layer. We are not only helping customers understand our JSF libraries, but also help them understand how to design an application with the user interface as a key component, and how building an excellent user experience can be a prime motivator for a Web application. We were surprised how much interest there is now in that.

Frank Sommers: As you talk to developers, what common mistakes are you observing developers make in the UI layer?

Jim Cook: We’re seeing two sorts of errors: some related to user experience design, others are more technical.

On the user experience side, developers often do not understand the business processes their users go through. Without that understanding, developers tend to put important information in inaccessible places. If developers paid more attention to the user, they’d know that that sort of information needs to be right near the surface of the application so that information people need is most readily available.

On the technical side, there is a fair bit of confusion about how to build stateful ecommerce apps. That’s surprising to me, given how long the Web has been around. At an enterprise, you might have one group of developers who want to build everything themselves using custom components; then there are those who’d rather use a JavaScript library, and there will be those who want to jump straight into Flex or Silverlight. Then there is usually someone in a company who points out that JSF is a community standard and that, maybe, they should be looking at that, too.

The problem is that most people see only part of the picture, and yet there are so many things you need to bring into the solution to make an ecommerce app work properly. At this time, JSF is the only Java platform that pulls everything together: It gives you state management, some security, a clean connection to your back-end, and gives you the ability to create customized front-ends that are really tailored to what you are trying to do. While people may become enamored of a technology, you need to keep in mind that any one technology is just a piece of the puzzle, and you need to make sure all the parts fit well together.

Centralizing server code around Java, and having some standards in that space, has been a great help. Things like Spring, Hibernate, or EJBs work well together: they’re pretty much like Lego blocks, you can snap things together on the server.

The client has not reached that level of standardization. As a result, there are more pitfalls in making choices. For example, if you want to get into Ajax and are looking to combine different libraries together, you can really get yourself into trouble, because those libraries will step on each others’ toes. Meanwhile, if you go with Flex, for instance, you have to be concerned about managing your server communication. You’d better have some fairly good experience with that before you can do it well.

But interoperability on the client is getting better. HTML 5 has some things that will standardize many of these issues. HTML 5 is wonderful, but is really just now beginning to find its way into browsers: The latest Internet Explorer version, for example, has not implemented any part of HTML 5. At the same time, JSF 2 has standardized Ajax within JSF applications. That will, I think, really pull the Java community toward JSF, and will solve many of the client-side interoperability problems.