JavaServer Faces vs. ASP.NET WebForms

JavaServer Faces vs. ASP.NET WebForms

Mike Richardson - ALTERthought, Inc.

Introduction:
Every year, the Microsoft and Java development communities have been attempting to develop methods to enhance developer productivity. Whether you are using the Microsoft Application Blocks for .NET or a number of the Jakarta frameworks like Struts and Ant, they have been designed to increase productivity and decrease the rate of development. Although .NET and Java have introduced many different frameworks, they are all striving for the same goal. That is, to bind the gap between rich client interfaces such as Swing and WinForms with web development paradigms. This gap has been created as a result of the HTTP protocol. Because the web is a stateless paradigm, it becomes very difficult to create rich user interfaces that can be bound easily to application events. For example, when developing in Swing and WinForms, it is a simple task to create UI components on a form and write code which reacts to events initiated by the user. This is why most highly interactive user interface applications are written in WinForms or Swing and not something which relies on the stateless nature of HTTP, like JSP or ASP.NET. With the introduction of ASP.NET WebForms and JavaServer Faces, this gap is beginning to close.
The purpose of this article is two-fold. First, I will explain how JSF and ASP.NET each implement their own set of UI event-driven web functionality even though they are both bound by the HTTP protocol. Second, I will discuss the differences in both technologies and their respective benefits and disadvantages.
ASP.NET and WinForms:
Although ASP.NET is a very loose implementation of the model-view-controller design pattern, it does follow several design patterns which make for an extremely productive, event-driven environment. For example, ASP.NET implements the Page controller pattern with its code-behind concept. Each page is composed of HTML and XML markup and a code-behind file which contains event handlers. By simply adding one line of code to the source file (a delegate binding), it is possible to "wire-up" any event to a control. ASP.NET 2.0, although it adds a host of new controls and security concepts, still follows the same design model. This model simplifies coding greatly, as developers can create web applications similar to classic Visual Basic programs. ASP.NET WebForms can be created by dragging controls onto forms and writing event handlers for these controls. The mechanism by which ASP.NET binds events is through a special class called a delegate. A delegate is a type-safe function pointer which allows the developer to call methods from user initiated actions. ASP.NET does all of this magic behind the scenes. The ASP.NET runtime is responsible for extracting event input from the WebForm to the server-side via HTTP, and then calling the appropriate developer specified method. The following illustrates creating a component and binding an appropriate event handler:
<input type=button id=”Button” value="test"
runat=server />
Button.ServerClick += new EventHandler(OnBlue);
All that is left to the developer is to implement the OnBlue method. The rest is handled by the framework and the ASP.NET runtime.
Recall that every .aspx page actually implements the Page object. A Page object contains zero or many controls, all of which render themselves as HTML code. If you are a control developer, you know that controls simply perform some type of logic, and then return HTML to the response stream. Basically, a Page object forms a logical control tree, and then asks each control to render itself. Each control then calls the corresponding render method and spits out HTML for any type of supported device or browser. The ultimate response stream contains all the HTML and JavaScript required to create the page output, including event binding information.
In ASP.NET, all events are initiated on the server-side, not the client side. It is important to understand that these server-side events are generated as part of the post-back sequence and are issued through the standard HTTP POST mechanism. As part of the HTTP payload, ASP.NET passes additional information with each POST request when server-side events are issued. In particular, there are two hidden fields on every .aspx page - the first contains an event target, and the second is populated with the event argument. When the POST is processed on the server, ASP.NET checks the contents of the hidden fields and fires events issued by the control whose ID is in the hidden field. This is how the HTTP protocol can be used to issue server-side events. This server-side event paradigm brings a familiar programming model to developers who are used to working with controls that issue events and render their current state, but may not be familiar with the disconnected nature of the HTTP protocol. Almost all of this functionality is hidden from the user - one of the design goals of both WebForms and JavaServer Faces, as I will demonstrate shortly.
JavaServer Faces:
Java Server Faces (JSF) is a user interface framework for Web applications using Java technology. JSF has been designed to ease the burden of developing and maintaining applications that run on Java application servers and render their user interfaces back to a target client. JSF leverages existing, standard UI and web-tier concepts without limiting developers to a particular markup language, protocol, or client device. JSF is designed to output markup text to any client device, as well as use existing web protocols such as HTTP. JSF includes two main components:
? Java APIs for user interface component management, state management, event handling, input validation, page navigation, internationalization, and accessibility.
? A JSP custom tag library for expressing the JSF user interface within a JSP page.

As will be illustrated, JSF is based on the Servlet and JSP technologies, making the development process more rapid by providing the features mentioned above.
A JSF application looks like any other Java Servlet/JSP application. It contains a deployment descriptor, JSP pages, custom tag libraries, and static resources. JSF applications contain JSP pages that host JSF UI components, such as command buttons, tables, input boxes, and most other popular UI widgets. Binding events to these controls is a simple process, much like ASP.NET.
What does JSF hope to solve?
In introducing what JSF hopes to solve, an analogy might be helpful. In a Java GUI application, such as Swing, there are a set of standard GUI components and an entire infrastructure for tweaking and extending the functionality. A Swing developer works with the concept of a Component - an element of the user interface, such as a panel, button, list, or table. Perhaps the most important Swing concept is that of events. For example, when a button is clicked, an event is generated. In Swing, it is easy to respond to these user interface events and write the corresponding response code. Similar to ASP.NET, JSF introduces a much different problem. In order to figure out, for example, that a button was clicked, the programmer or tool must analyze the HTTP request and try to determine what has happened. This is not an ideal situation and many frameworks have been created to encapsulate this functionality. The developer shouldn’t have to work with HTTP directly to figure out whether a button, image, or hyperlink has been clicked, or how these pieces fit together to create a response stream. What if Java programmers had a user interface development environment similar to Swing or even Visual Basic 6.0? This is the problem JSF aims to solve.
Event Binding in JSF:
In terms of development, JSF is remarkably similar to ASP.NET WebForms. Although the specification defines two different roles for developing JSF apps, I will not focus on them here. Suffice it to say that a developer can simply create UI widgets on a JSP form. In addition, it is easy to bind events to these components and react to them in the business layer. The server will take care of which component fired which event and leave it up to the developer to create the business logic, thereby increasing development time.
As I described earlier, a JSF application looks like any other Servlet/JSP application. The user interface of a JSF application consists of JSP pages which host JSP components, such as forms, input boxes, and buttons. These components are represented by JSF custom tags and can hold data. In fact, on the back end, a JSF page is actually represented by a component tree that will be rendered on the client in a top-down fashion, with each component writing out its own HTML to the output stream. Just as in most other web and Java frameworks, JavaBeans are used to store the data a user entered on the form.
A JSF application works by processing events triggered by JSF UI components on the page. These events are caused by user interactions. For example, when a user clicks on a UICommand button, a particular event is fired. The JSF programmer will decide what to do when an event is fired. This is done by writing “event listeners”. In other words, like ASP.NET, a JSF application is fully event-driven. By implementing two types of listeners (ActionListeners and ValueChangedListeners), developers can bind events to controls in the same way as ASP.NET. The following code illustrates an example of binding an event to a JSF command button component.
<%@ taglib uri=”http://java.sun.com/jsf/html ” prefix=”h” %>
<%@ taglib uri=”http://java.sun.com/jsf/core ” prefix=”f” %>
<h:command_button id=”submitButton” label=”test” commandName=”submit”>
<f:action_listener type=”com.alterthought.MyActionListener”/>
</h:command_button>
By writing a class which implements the javax.faces.event.ActionListener interface, events can be bound to controls over the HTTP protocol. Similar to ASP.NET, the id of the control and all the event information is packed into the HTTP payload. The processing cycle on the server, although beyond the scope of this article, is responsible for calling the appropriate developer created method. In essence, this creates the notion of even-driven, rich user interface programming.
As I have illustrated, Microsoft and Sun have lead us into a new era in Internet application development. The time is now gone when HTML pages were produced manually using scripting code intermixed with HTML. We will now be creating applications based on a real event-driven programming model and component paradigm.
Now that I have explained the basics of each technology, the rest of this article will focus on the differences between ASP.NET WebForms and JavaServer Faces. JSF is still in draft and many changes are being made, so this may make some of my assertions a little out of date.
Architectural differences:
As I have illustrated, there are many similarities between WebForms and JSF. Each technology hides the intricacies of the HTTP protocol and event binding. However, there are some key differences between the two technologies:
? ASP.NET and Web Forms support a single templating mechanism; JSF defaults to JSP, but can support alternative template mechanisms as well, such as Velocity.
? Web Forms components support encoding and decoding directly; JSF components can encode and decode themselves directly, but the framework also has extensive support for separate RendererKits and Renderers, which means that the look and feel for an application is pluggable, as long as the layout of the components is constant. RenderKits also allow the same components to support multiple devices easily -- just develop a new RenderKit -- the component itself doesn't have to worry about it.
? Web Forms applications use the Page Controller  pattern -- each page is a class that posts back to itself to handle events. This is much like the VB-style form-based approach (also made popular by Borland's Delphi). JSF, by contrast, uses a more strict MVC approach to event handling -- application events are handled by Action classes (much like Struts), and component events are handled by listeners (traditional JavaBeans event handling). JSF can, however, support the WebForms-style of development as well (the technical details, however, are quite different). For example, a JSF application can bind a control to an event in a backing bean simply by declaring it in the component’s action attribute. The details are hidden by the FacesServlet and FacesContext, but the results are the same as if an ActionListener were implemented.

? Web Forms has extensive support for integration with client-side scripting languages (such as JavaScript); JSF currently has no such explicit support. This means that it's currently easier to write components that use a lot of client-side scripting in Web Forms (and the existing components make heavier use of scripts as well, such as the calendar control).
? WebForms come with a host of controls such as DataGrids and DataLists that are used to bind directly to data sources. No such controls exist in JSF.

Summary:
As I have illustrated, Microsoft ASP.NET and JavaServer Faces bring event-driven programming to the web. They both are responsible for abstracting the necessary intricacies involved in web programming and its stateless nature. Although most web applications still rely on JavaScript, these two technologies make creating rich user interfaces a much easier, and more importantly, faster task.