Java Web controls
PageBox is a deployment facility. Authors publish something on a Repository. Assemblers subscribe to the Repository to get publish stuff installed in their environment.
PageBox aims to address the deployment and versioning hell:
We provide PHP, .NET and J2EE versions because we believe that an effective solution has to work with all these environments. In this document we describe our approach for the second Java version.
We wrote that PageBox allows publishing and deploying something. This thing can be an independent Web Application. However to address portal needs we should deploy thinner units, controls. There is no common definition of Web Controls. We must define what we support in each environment.
The development of dynamic Web pages is a form of Graphical User Interface (GUI) development. Like other GUI development it requires combining three aspects:
We start by a bit of history. It is a high level description but it comes from the guts. Then the author wrote ad nauseam Macintosh, Windows and X-Window programs and found a strong motivation to write TCL and then VB.
This description is high level.
Macintosh, Windows, X-Windows Graphical system include an input routing:
You have only one keyboard and one mouse and run concurrently many applications on the machine. The system knows which application has the focus and route your keystrokes and mouse events to this application. For performance reasons the system has been improved: if the application is not interested by the mouse move, it doesn’t need to constantly check the cursor position.
Graphical application followed the same model:
Graphical elements could be described by text files called resources.
Initially (Windows and Macintosh C APIs) programmers had to write the loop. Then products like VB and frameworks like MFC hided the loop.
This model allowed the creation of extensible applications. The executable ran the loop and acted as a container. It hosted controls. The most famous control model was COM (Component Object Model) of Microsoft.
A COM control is a shared library that contains a set of resources and callback routines and than can be dynamically loaded to a graphical application.
Controls had significant benefits:
Arguably object development started with Graphical development and happened before the release of object languages. Macintosh and X development used to be tedious for that reason (huge function names, handle parameters). Then there were no hype surrounding objects and designers tried to keep the things as simple as possible.
Smalltalk introduced two innovations:
Here is a definition coming from "How to use Model-View-Controller" by Steve Burbeck (1987): "The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller)."
The definition is too close for Web applications. We suggest the following definition:
Model-View-Controller defines three roles
The HTTP architecture is simpler, more flexible and relies on human-readable text.
Graphical elements, described by resources in classical GUIs, are described in HTML or in XML with the help of Cascading Style Sheets (CSS). The browser interprets the HTML or XML code and displays the graphical elements.
The Web application server is a stateless TCP server. When it receives a browser request the server routes it to a server component according to its URL. The server component can be:
The server component interprets the input, makes some processing and sends a HTML or XML response. It is where the HTTP flexibility can become a development challenge.
First the input comes from placeholders in the HTML stream. A server component B will receive input1, input 2 and input because:
As the example of ASP.NET shows, nothing prevents to build an architecture on top of HTTP that addresses these drawbacks, but such an architecture is not standardized. We believe that these drawbacks prevent the development of Server controls and that it is a significant issue.
Java development followed a different track based on MVC that we present now.
Java Web development
Most of the Java Application servers conform to the J2EE standards.
A servlet is a Java class that gets instantiated and called when a user makes a HTTP request with an URL managed by this servlet. A servlet looks like this:
The server is compiled code and the Application server manages the servlet lifecycle. Because a servlet is written in Java code it handles well the state and logic. Servlets are not good at producing content. A servlet has to send to the browser every part of the user interface including the placeholders for the subsequent user inputs. Servlets are not good either at interpreting the input. In the case above:
JavaServer Pages (JSP) are a special form of servlets. JSPs are precompiled from HTML / XML pages that contain JSP tags. JSPs solve the content production problem of the servlets. However JSPs are not as good as servlets to handle the logic: the author can code the logic in taglibs or in Java islands in the middle of HTML or XML code. Such code is tough to debug and to maintain.
The J2EE designer can combine servlets, JSPs, Java Beans and regular Java classes to build an application more modular and easier to maintain. All J2EE designers face the same problem and some design models, based on the MVC architecture came out as the most effective solutions.
The page author declares that a JSP page will use tags defined in a tag library with
The uri refer to a taglib element of the deployment descriptor. The prefix defines the name space of the tag library.
A tag library implements custom actions. The page author defines a custom action with an XML syntax, for instance:
A tag handler class stored in the tag library implements the logic behind the custom tag. A Tag Library Descriptor (TLD) defines which tag handler class must be called to process each custom tag.
For more information you can read the Sun Tag Library tutorial.
Though Custom tag processing is implementation-dependent it generally works in that way: At pre-processing time the JSP is converted in a special servlet class that calls the tag handler methods and the TLD is not used at runtime.
It is feasible and useful to use PageBox to distribute tag libraries. However tag libraries extend the JSP language and don’t act as controls. Therefore we need:
JSTL stands for JSP Standard Tag Library. JSTL is both:
JSTL contains four libraries:
JSTL also defines an Expression Language (EL) for accessing runtime data from various sources.
After reviewing the Web development building blocks we can describe how these blocks are commonly used with the MVC architecture.
In the model 1, the presentation layer – the view – invokes the controller, which then uses the model to build the data rendered by the view. The model 1 is generally better in term of performance and readability.
In the model 2, the request is first processed by a controller servlet. The controller servlet uses the dispatcher to forward the request to a view handler, usually a JSP. In the model 2 the controller and the view are decoupled, which means that it is easier to reuse the view. When a different view has to be displayed depending on the processing result the model 2 is simpler.
Frameworks have been written to simplify the development of MVC Web applications. We briefly present two of these frameworks that are Open Source. They share two drawbacks:
The support of Java Controls in PageBox should be compatible with both frameworks.
You can download Struts and browse its documentation at http://jakarta.apache.org/struts/. Struts belongs to the Jakarta (Tomcat) family of products, which tends to be the test bed of the new Java technologies and its documentation is more comprehensive than the documentation of WebWork. Note that a version of Struts is included in the Java Web Services Developer Pack and that Struts is described in the Java Web Services Tutorial from Sun.
You can download WebWork and browse its documentation at http://www.opensymphony.com/webwork/. WebWork has a simpler API than Struts.
Portlets are building blocks of Portals products. Portal products are products designed to help writing portals and portals are Web applications that offer pages whose content comes from different Web sites. A portal typically supports:
While servlets interact directly with browsers, portlets interact indirectly with browsers through portal products, via a request response paradigm implemented by the portlet container. Portlets are designed to be aggregated in the context of a portal page.
A Portlet is a portal control, a component able to render its content. A Portlet can be packaged in a specific Web archive. Therefore Portlets meet every requirement of Pagebox deployment. Furthermore PageBox would improve the Portlets value. Consider the case of a Portlet who knows how to call a Web service and display its response. If it can update this Portlet on all subscribing sites the Web service provider solves its Web service versioning problem.
PageBox can also be used to distribute database updates and to pre-load a part of the remote content. Caches – at least the Caches of the Enterprise portals – have a problem. A cache gets updated when a user makes a request. Therefore the caches are updated mostly in the morning and especially on the Monday morning.
Portlets should be standardized by JSR 168.
For the moment the best we can do is to support the Jetspeed Portlets. Jetspeed is Open Source and belongs to the Jakarta family of products.
Control Framework in Java
However Portlets are not a general-purpose solution. First portal products such as Jetspeed are almost as huge as MVC frameworks. Second Portlets are designed to be assembled in portal pages without programming using a Portal Structure Markup Language (PSML) in case of Jetspeed. This model even allows the end user to customize its page.
We can need a smaller control framework. We present its design guidelines below.
The Control framework has a Model-1 architecture.
A JSP acts as a simple container where controls are included using a PageBoxTag Tag lib.
We implement the tag handler like this:
The Model part of the PageBox control must implement a PageBox.Model interface.
PageBox.Control is a class that:
Before looking at the View part, we must closely a working example, the .NET controls.
Controls in .NET
Let’s take the example of PolLogin, a user control defined in Polaris. The rendering is defined in a .ascx file like this:
Here is how this code translates in HTML:
As we can expect an element like <asp:textbox> is translated into an <input> tag.
The id of the <asp:textbox id=User> is translated in a name Login:User made of the ID of the user control in the page and of the textbox ID. This ID is unique in the page.
<asp:textbox id=User> has a special handling. A peer User object System.Web.UI.WebControls.TextBox is defined as a member of the PolLogin.ascx.cs class.
When the user clicks on the ButLogin button the .NET framework parses the Request parameters.
Parameters that starts with Login are routed to the PolLogin control whose ID is Login.
Then the .NET searches an object matching the remaining part of the Request parameter and in case of Login:User finds the User peer object and sets its Text attribute to the value of the Request parameter.
The same routing takes place in case of buttons. However in this case the framework calls the callback method defined by:
OnLogin is a method of PolLogin.ascx.cs with this prototype:
Cherry on the cake, to update <asp:label id=labStatus> whose peer object is labStatus we only need to update its text attribute.
We plan to implement the View using a JSP and tag handlers defined in the PageBoxTag tag lib responsible to: