I have recently had the opportunity to work on an application utilizing ICEFaces ICE components and have been learning more about the product. This was the first time I have had the opportunity to look at some of the component-based libraries and to work with JSF. Originally, I thought I might give a little tutorial on how to use some of the components, but I’ve had enough people ask “What is ICEFaces?” that I thought it might be nice to step back to the 1,000-foot level and take a look at what component libraries are in the grand scheme of Java development.
Some widely-used request based frameworks started to come along and give hope for a cleaner future, allowing the developer to focus more on the business logic at hand. For many, the first introduction to these types of MVC frameworks was the open source framework Apache Struts, formerly known as Jakarata Struts in the early 2000′s. Struts forced a separation in the logic between the model, the view and the controller. Struts is request-based, utilizes a single controller and has a large custom JSP tag library. Flexible validation was now automatically available for form elements. However, some of the common developer complaints of Struts were that it was very configuration-intensive and that the structure could be rigid. For example, the (original) required usage of JSP. With a recent release of Struts2, it still has some strong fans. Struts is well documented, mature and Struts2 offers extensibility via plug-ins. Struts now allows for the use of any view technology that can be rendered via a Servlet.
I don’t mean to imply that JSF, and other component based MVC frameworks such as Wicket, Play, and Tapestry are the next step, but rather that they offer different possibilities. What to use in these cases depends heavily on what you need to do. As with anything, it’s a give and take.
However, the aforementioned products such as Struts and Spring MVC are all request-based MVC implementations (sometimes referred to as action-based implementations). Actions are completed by the requested and then sent to the view to be rendered. State is not maintained between requests. JSF and other comparable products depart from the conventional model and use a component base. What does this mean? Component-based implementations can be seen as starting with the view layer and working back. Components are simply pieces of UI code that are reusable and define functionality and behavior. In contrast to request-based frameworks. the state of the view is maintained between requests for a session, which allows for easier server-side validation and value change event handling. Component-based frameworks allow you to do more with less view code.
JSF is Sun’s standard implementation. Many common activities for a web application are handled in JSF allowing the developer to focus on the business logic at hand. This includes page navigation, standard user interface components, and error and event handling. JSF’s recommended display technology is Facelets, which are xml-based. JSF uses templating so you can create a page that acts as a base for other pages via Facelet tags. JSF lets you create composite components and gives you built in AJAX. JSF still allows for the use of Spring and similar technologies (although Spring MVC is not recommended in combination due to the inherent request-based/component-based difference). State management is supported. Oh, and JSF2 will let you to easily create your own HTML5 composite components, taking advantage of the power of the capabilities of running on iOs, Android and Chrome.
As a very brief overview, JSF works essentially as follows: you have your component rendering model made up of the aforementioned UI components in the form of tags. There is a conversion model that can optionally associate a component with a server side object. Then there is the event and listener model used to handle events generated by UI components. There is also an validation model that allows for common data validation checks before the model data is updated.
Okay, so now that we’ve stepped through all of this, if you haven’t seen an example from a component library, I’m going to list a couple here. I’m focusing just on the view and not the whole picture for brevity, but these should help give you an idea of how powerful these components can be for building standard UI components quickly and easily. If you are interested in-depth on how the various component-based MVC’s work, and specifically how JSF works on a broad level, there are a lot of books and websites on the topic. It’s a massive subject, but an interesting one.
My intent is not to promote ICEFaces over one of the other component libraries, such as PrimeFaces (which is actually used by many of the ICEFaces components), but rather to give a quick example of the components available for use. ICEFaces has released ACE Components, which includes a lot of useful components. For example: let’s say you need to have the user enter a date and time – a pretty common need. Okay, do you want it to be rendered inline or as a popup? Do you need a specific timezone? What about a specific format? Okay, good, then you can use the ace:datetimeentry component. With this you can now specify your need for a popup or inline entry. You can set up the format to match any pattern that can be used by the Java
SimpleDateTimeFormat and your timezone can be determined by the use of a Java TimeZone (if you are wondering what these are run
TimeZone.getAvailableIDs()). The component can be set up as follows:
Or, lets say you need something to have masked entry on input, such as a date of birth or a phone number. Or what if you need a progress bar that can poll, or an easy to use file entry or printer component, or a chart? Yes, all available and ready to use.
For more information about these frameworks, here are a few helpful links:
For a further demonstration of components and putting it all together, stay tuned for my next blog entry.
– Adrienne Gessler,