Component-Based Java Frameworks

Adrienne Gessler Development Technologies, Java, Spring 2 Comments

Attention: The following article was published over 12 years ago, and the information provided may be aged or outdated. Please keep that in mind as you read the post.

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.

First, in order to get to what component-based products offer a developer, I thought it might be fun to look a little bit at the evolution of the Java MVC frameworks over the last 10-12 years. Because if I had, say, suddenly gone from working on a very old-school Java web app many years ago (which may have had very little in the way of MVC usage, been heavy on plain JavaScript in the page and had embedded business and control logic), and then suddenly seen a web component library for the first time, I’m pretty sure that I would have started screaming and jumping up and down in excitement over the possibilities. Luckily for my co-workers, that was not the progression. But, nonetheless, I find it interesting.

As readers are no doubt aware, over time the MVC frameworks for Java have made the building, implementation and maintenance of layered web architectures much quicker and easier. Long gone (hopefully) are the days of JSP pages with cumbersome JavaScript and the often frightening potential for embedded Java Scriptlets and business logic. Those pages that made you want to scream and rip your hair out when you realized that the long-ago-created-by-someone-else JSP that you needed to fix an error in was over 4000 mind-boggling, messy lines of display with business and control logic mingled together (ahem, yes, this may be a specific example, but I will not confirm). The standard Servlet and JSP API’s alone frequently left applications open to inconsistent use of MVC and the potential for difficult maintenance issues like the aforementioned JSP. Form input was often always a String requiring extensive JavaScript validation to prevent system errors on type conversions. The potential to easily apply the application business logic in a different type of application was missing because of the business and control logic in the view.

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.

In response to some of these issues, lightweight request-based frameworks started to be created and used, such as Spring MVC and Stripes. After the advent of annotations in Java, these frameworks often used annotations to drastically reduce the amount of configuration needed. To use Spring MVC as an example: it clearly separates business, navigation and presentation logic. It’s highly configurable and allows for the use of inversion of control. A Spring tag library is also available, if you choose to use it. Spring MVC allows you to use any object as a form object, meaning that you don’t have to duplicate the logic on your business objects again in your form validations. Spring offers Spring Mobile which is an extension of Spring MVC intended to make mobile development more simple. And as far as your view resolution goes, it is highly flexible. Your view can be whatever you want it to be. Want to use a JavaScript UI library such as JQuery UI, or Velocity, or JSP with or without JSTL? Great. The possibilities are wide open. However, the flexibility can mean that one way or the other you will be writing some or all of the html, css and js yourself. This gives you great control. Sometimes, that’s exactly what you need and want. Other times, it can be nice to have these elements in a prepared package.

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.

If you are using a product like JSF, you will have much less control over generation of rendered html, css and js. However, in some cases a component based MVC may be for you. Don’t get too excited though, just because a lot of the components can help you quickly create a UI does not imply that development is now “easy” or that you don’t need to understand what’s going on under the hood. Even though some of the components libraries limit the use JavaScript in an application, they are still often built on JS libraries and frequently utilize JQuery for a base. In my opinion, you will still need to have a a good understanding of JavaScript in order to troubleshoot issues and have the understanding needed to build your own components and set up customized Ajax behavior (now you are glad you slogged through that 4000-line JSP so many years ago, aren’t you?).

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.

A couple of the major players in JSF implementations are Apache MyFaces and Oracle Mojarra. An implementation of JSF simply implements the basic specifications for JSF. This is where most of the standard components are going to come from. This includes UI components like forms, tables, columns, messages and select items – the UI components that you would expect to see. This is in contrast to a component library, which is where the special features and combined components come in. Since JSF is the Java EE standard, it’s available through a lot of third-party component libraries including PrimeFaces, RichFaces, IceFaces, OpenFaces and Tomahawk. So, back to the question that started all of this – what is ICEFaces? ICEFaces is an open source component library for JSF that utilizes Java-based coding for client side interaction and AJAX, limiting and omitting the use of JavaScript. Many of the component libraries support mobile application development as well as web development. For example, ICEFaces offers ICEmobile and PrimeFaces offers PrimeFaces Mobile, which is based on JQuery Mobile.

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:

<ace:dateTimeEntry id="myUserCal"
value="#{datePopup.selectedDate}"
timeZone="America/Chicago"
pattern="MMM/dd/yyyy"
renderAsPopup="false"/>

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, [email protected]

0 0 votes
Article Rating
Subscribe
Notify of
guest

2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments