JWebComponents

What is JWebComponents?

JWebComponents is a set of graphical components for building interactive web applications designed in a way to foster the following things:

• The separation of application logic from the details of HTTP request and response processing
• The separation of application logic from the details of web application state management
• The separation of application logic from graphical presentation

To these ends, JWebComponents was designed with the Model-View-Controller design pattern in mind. Each component is subdivided into 3 parts: the model, the view, and the controller. The model is responsible for managing the state of the component, the view is responsible for the graphical representation of the component, and the controller is responsible for processing user input.

JWebComponents models have the flexibility to persist their state in 2 different ways: on the client or on the server. Client-side state is transferred from the server to the client in a HTTP response, persisted in either HTML elements, cookies, or other client-side storage mechanism, and then transferred back to the server in a HTTP request. On the other hand, server-side state remains on the server persisted in thread local storage, a database, or other server-side persistence mechanism. Regardless of the persistence mechanism, the rest of the component does not change.

JWebComponents views have the flexibility to present components in a multitude of different ways, however only one way to currently provided. The currently provided mechanism serializes the components into SAX events which are in turn transformed into HTML using a XSLT style-sheet. The resulting HTML is sent to the client in a HTTP response. In the future it is hoped that a JSP based presentation mechanism can be added. Regardless of the presentation mechanism, the rest of the component does not change.

All JWebComponents components share the same controller. The controller consists of a single servlet. The controller servlet is interface between JWebComponents and the servlet container and eventually the client. It receives HTTP requests, applys application state, fires events in response to user input (e.g. mouse clicks), extracts application state, and returns HTTP responses.

In total, JWebComponents allows developers to build web applications using idioms similar to those found in other GUI frameworks (e.g. Swing) with a minimum of low-level HTTP request/response processing logic and web application state management logic and with a clear separation of presentation from application logic.

How does JWebComponents differ from other web application frameworks?

Struts

JWebComponents differs from conventional web application frameworks like Struts in many ways. The most profound difference is that JWebComponents does not use the command model. In the command model events on the client (e.g. clicking a button) are mapped to command objects on the server (e.g. PriceOrder). On the other hand, JWebComponents uses an event based model. Events on the client (e.g. clicking on a button) are mapped to equivalent events on the server (clicking on a button). With JWebComponents every user interface component on the client has a corresponding component on the server. Disclaimer: the author has never actually used Struts, so some of this information may be inaccurate.

JavaServer Faces

JavaServer Faces is on the surface very similar to JWebComponents. Each has server-side components that model client-side user-interface components (e.g. HTML input tag). Each has the ability to render the components to varied devices. However, they differ in at least the following ways:

• JWebComponents provides richer support for component state management.
• With JWebComponents, default values, event handlers, component properties are specified in Java code, while with JavaServer faces they are specified in JavaServer pages.
.
• With JWebComponents, every web page has a corresponding Page component on the server. This is not true of JavaServer Faces.
• JWebComponents comes with XSLT-based renderer, while JavaServer Faces comes with a JSP-based renderer.