JSF Central - InFact Uses JSF to Power Book Search Portal
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
InFact Uses JSF to Power Book Search Portal
 
InFact Uses JSF to Power Book Search Portal
by Rajiv Balachandran, Satish Bhatti
16 Feb 2007 02:30 EST

In this article, two developers discuss the ups and downs of using JSF to develop the public-facing InFact® Book Search site.


This article provides a brief description of our first JSF project, the development of a web application for the InFact® Book Search site (see Figure 1). We share our experiences—from choosing JSF as our framework to implementation and system testing and deployment—to help you decide whether JSF is the right choice for your current or future projects.

  Figure 2. InFact Book Search results for "Napoleon".
Figure 2. InFact Book Search results for "Napoleon".

The Decision to Go with JSF and MyFaces

When we began work on Infact Book Search, our primary requirement was to develop a web-based application that would provide an intuitive and easy-to-navigate interface to search the corpus of publicly available ebooks. This web application would communicate with the InFact back end through a Java API and harness the various search capabilities and features provided by the InFact system and present them to the user.

We looked at existing web development frameworks, including Struts and Tapestry. Although we didn't come across many serious live JSF deployments, we decided to go with JSF. Our decision was influenced by its powerful rendering model and extensive out-of-the-box components, as well as the ability to develop custom components, MVC support, an active and responsive JSF developer community, and the fact that JSF is now a Java EE standard. JSF also had some key features that we were looking for: the ability to map iterative data structures (search results) to UI components (JSF data tables and MyFaces Tomahawk data lists), the creation of a flexible reusable architecture, and the clean separation of the front end from the implementation logic.

We developed a relatively simple prototype in order to explore JSF features. This took us about a week. The quality of the prototype helped convince our project lead that JSF was the right choice.

For the development environment, we used Eclipse 3.1 with the MyEclipse plug-in (professional edition). The first phase of the project was completed in less than three months starting from scratch. The initial feedback was very positive and was followed by requests to make some significant changes in the layout and features of the application. Our flexible, re-usable architecture for the backing bean and helper classes helped us to incorporate these changes surprisingly quickly (see Figure 2). At this point, we considered how long it would have taken us to make these same changes using the other frameworks we were familiar with, and we were glad we chose to go the JSF route.

  Figure 2. InFact Book Search architecture.
Figure 2. InFact Book Search architecture.

After evaluating the existing implementations of the JSF spec, we decided to go with the Apache MyFaces implementation. The primary reason was the large user community with its reputation for active contributions and feedback. Furthermore, the MyFaces community seemed to be doing a great job of helping new users get over the JSF learning curve. The Tomahawk extension components and Oracle's donation to the MyFaces project (now named Trinidad) were even more compelling reasons to go with MyFaces. The InFact Book Search site is deployed on Tomcat 5.5 on Linux Debian and uses JSP 2.0 with HTML renderers and MyFaces 1.1.3.

The JSF Learning Curve

The first few weeks we found ourselves constantly struggling with the JSF learning curve. Every time we thought we had a handle on JSF, we would come across some new issue that exposed our lack of familiarity with a part of the JSF framework that we had not encountered before. This was in part due to the fact that JSF has evolved to be a complex framework in order to remain flexible and reusable. The evolving JSF spec that is under active discussion and development was another reason.

The high point that validated our decision to go with JSF was when we were required to make a significant change to the contents of one of the pages in the InFact Book Search application. We completed this in less than a day thanks to the powerful binding mechanism in JSF and our bean and helper class architecture. We could not help but try to estimate the time that this change would have taken if we were using some of the frameworks we had used in the past and the numbers we came up with were not pretty.

The Ups and Downs

We also had some concerns about the size of the HTML pages generated by our JSF views. After some careful review, we tuned some of the state-saving parameters for JSF and optimized our parameter passing between requests to get significant drops in generated page sizes. Our concerns of handling multiple users and performance under load by the JSF framework were alleviated when the system performed with acceptable response times when tested extensively with JMeter scripts (10 threads with 1000 queries per user).

One of other issues we faced that stands unresolved is the inability to bookmark JSF-generated pages. This is because JSF uses POST requests and performs a form submit for every Command component. The ability to bookmark individual books was particularly important for this site. We realized that this is a problem that many developers in the JSF community currently face. We adopted the workaround of using HtmlOutputLink components and passing request parameters the old-fashioned way for our key links. The Sun developer forums as well as members in the MyFaces community have suggested a few workarounds to this problem, and we are confident a solution will find its way into these implementations and possibly the JSF spec down the line.

The JSF rendering model, out-of-the-box user interface components, and support for the MVC architecture helped us in designing our application with a clean separation between the view and the back-end components. The JSF rendered attribute that controls the rendering of child components was particularly useful in keeping our JSP pages free of any conditional rendering logic. The faces configuration file was very manageable and a big improvement when compared to a equivalent Struts configuration XML file.

The Bottom Line

The feedback for InFact Book Search so far has been positive. The flexibility and quality of the Apache MyFaces implementation of JSF has played an important role in this. We are currently working on developing custom JSF components that will be used for rendering UI components specific to the book search application. We also plan on incorporating Facelets into our future releases. Overall, our experiences implementing our first JSF project leads us to believe that we will be able to reduce our development time on future projects using JSF. This is largely due to the ability to create easy-to-maintain JSP pages and use third-party JSF components. Building a library of reusable custom components would be a step in that direction.

Resources

We utilized a number of JSF resources during this project, especially during the early stages. These resources proved invaluable in helping us get up to speed with the framework, learn some JSF tips and tricks, and work around bugs and include:




RSS feed(all feeds)

The Editor's Desk
Podcasts
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2014 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.