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:

• It is tough to deploy and maintain a Web application on a large number of servers whereas large-scale deployment would reduce bandwidth requirement and improve the scalability and reliability

• Each time a Web service is updated (1) The provider must maintain old versions (2) The consumers must update their code to use the new functions

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:

• Input parsing

• Business logic

• Output production

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:

• They allowed extending applications with off-the-shelf components

• They allowed using the most effective language for each task, for instance write the Graphical and the Business part in VB and write the technical part dealing with bits and drivers in C++

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:

• Object marketing: Objects were good because they allowed reuse and simplified maintenance and Smalltalk was the best object language

• The Model-View-Controller (MVC) architecture.

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 controller that interprets the input

• The view that generates the output

• The model that handles the state and the logic

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:

• A CGI program

• A servlet or JavaServer Page (JSP)

• An Active Server Page (ASP) or an .NET ASPX

• A script (PHP, Perl...)

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:

• The server component B was defined as the component responsible to handle URL B’ requests

• A form was defined in a HTML stream with URL B’ as the action destination

• This form contained three input fields, input1, input2, input3

• The HTML stream was produced by a static page or by a server component A

Drawbacks:

• There is nothing in the code that establishes a link between components A and B

• The author of A has to know which inputs B requires

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.

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:

1. The servlet must know what to do of myfield

2. The page that invokes MyServlet must contain a myField input field

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.

Custom tags

• Are implemented in tag libraries

• Can be customized via attributes passed from the calling page

• Have access to all the objects available to JSP pages

• Can modify the response generated by the calling page

• Can communicate with each other

• Can be nested within one another

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:

1. To support coarser grained controls

2. To specifically describe the Tag library support in PageBox

JSTL stands for JSP Standard Tag Library. JSTL is both:

• A good example of what can be done with a Tag Library

• A standard library that we are likely to use in Web controls

JSTL contains four libraries:

• Core. The core allows defining conditions, loops...

• XML. The XML library allows parsing XML documents and applying an XSL transformation

• I18N. Internationalization and formatting

• Database access

JSTL also defines an Expression Language (EL) for accessing runtime data from various sources.

We can read JSP Standard Tag Libraries, Part 1 and Part 2 by Sue Spielman and JSTL 1.0: Standardizing JSP, Part 1 by Hans Bergsten.

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:

• They are big. Because of that Control programmers shouldn’t assume that they are installed on target systems except if the framework itself is installed by PageBox (which should become possible in the coming months)

• There are overlapping areas between some of their functions and JSTL

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:

• Personalization. The portal user can select the components to display

• Syndication. The portal gets content from different Web sites using XML dialects such as Rich Site Summary (RSS)

• Caching of the remote content

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.

Note:

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.

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:

1. Implements the Controller of the PageBox control

2. Instantiate or reuse the Model and the View parts of the PageBox control

3. Parses the parms String. The parms string is a set of name-value pairs separated by semi colons. For each name-value pair PageBox.Control calls a setXxxx method of the PageBox model

4. Calls the methods of the control Model according to the Request parameters

Before looking at the View part, we must closely a working example, the .NET controls.

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.

Pros:

• Security. The control only sees the data that it manages

• Modularity. The parameters of a control instance are unique

• Simplicity: It is easier and safer to implement callback methods that retrieve relevant parameters from member objects and set updated values in these member objects

Cons:

• Good as far as you stay on the same page

We plan to implement the View using a JSP and tag handlers defined in the PageBoxTag tag lib responsible to:

• Define unique HTML tag names

• Make these tag names available to ControlTag. Then ControlTag will be able to set the corresponding member variables of the model. When a HTML button triggers a server action ControlTag will be able to call a callback method of the model.

• Retrieve the corresponding member variable of the model and sets the element content accordingly

Notes:

• The control framework can be used on multiple pages as far as all these pages include the control

• We can use the View to generate a skeleton of the model

Java PHP .NET
Reservation Controls Java controls
Polaris Grid Coordinator Grid V2
Distribution Installation NWS

Contact:support@pagebox.net
©2001-2004 Alexis Grandemange   Last modified