Why Click

This topic discusses the design philosophy and background behind Click, and hopefully explains why someone would build another Java web application framework.

Click is a modern JEE web application framework, providing a natural rich client style programming model.   Key features of Click include:

1.  Simple to Learn

To support ease of adoption Click has some of the best documentation available for an open source framework and includes many working examples.

2.  Component and Page Oriented Design

One of the first generation JEE web frameworks was Struts, which provides a command pattern design and a set of JSP tag libs. Unfortunately with Struts you are still down in the weeds, mapping URLs to Actions and working with primitive ActionForms. Its not giving you much leverage at all.

Tapestry was one of the first component based JEE web frameworks, introducing component hierarchies, pages and an event based programming model. This is a much more productive way of working, and is what we have come to expect when developing desktop GUI applications.

The idea with Click was to take this page and component design approach, and make it much easier to use and more accessible.

Click provides a Page oriented design, featuring Control components and an event based programming model. Click includes 40 Controls out of the box, which correspond to the major HTML elements. It's a great way of programming more simply.

Click Forms and Controls provide automatic validation and rendering, making form development very fast and robust.

3.  JSP & MVC Free

JSP's combined with the miss application of the MVC pattern have been holding back JEE web development for many years. It's a big statement I know, please let me explain.

MVC is a desktop GUI design pattern, which supports a separation of roles in UI design. Model is the data, the View does the rendering and the Control is for modifying the data. Now MVC is a fairly sophisticated UI pattern which solves the problem of multiple views and controls sharing the same data.

For most UI development however MVC is overkill. The control and the view are usually the same thing. For example, a Select box is the view and the control and also holds the model. In Swing fortunately, most of the MVC design is hidden away below the surface. In VB and Delphi there is no MVC at all.

In the early days of JEE web development design patterns were highly coveted, and MVC was grabbed and early Servlet/JSP designs were branded as MVC. In their analysis the model was usually a DAO, the view was the JSP and control was a Servlet.

The effect of this was to lock in the design concept where the UI MVC roles were strictly separated. This fits well with the generalized architectural principle separating layers, and with the fact that JSPs are only really suitable for rendering output.

Unfortunately the cost of this strict separation was the encapsulation. Most rich client UI components encapsulate their rendering and control functionality. Click components (Controls) are responsible for both rendering themselves (view) and then understanding what they mean (control).

To see this concept in action take a simple Click page where we have an ActionLink Control.

public class ExamplePage extends Page {

    @Bindable protected ActionLink myLink = new ActionLink(this, "onClick");
    
    public boolean onClick() {
        System.out.println("onClick invoked");
        return true;
    }
} 

<a href="$myLink.href">Click Me</a>

<a href="/mycorp/example-page.htm?actionLink=myLink">Click Me</a>

Conversely with the JSP MVC architecture a JSP can tell you something, but it can't understand what it has just said. Think about this for a second. There is no single UI component that is taking responsibility for its own actions. Guess where the responsibility then falls to...

You become responsible for wiring up the numerous pieces to make it work. In Struts this can include:

• writing a custom Action class
• writing a custom ActionForm class
• specifying the action elements in the struts-config.xml file
• specifying the form-bean element in the struts-config.xml file
• specifying the form element in the validation.xml file
• specifying the form field validation elements in the validation.xml file
• ensure all bindings are correct between the XML elements: action, form-bean, form, field
• specifying the tag lib includes in the JSP file
• specifying the <htm:form> and <html> field tag XML elements and attributes correctly in the JSP file

Another aspect of these designs is the transfer of logic from Java code into XML configuration files. Tapestry and Spring MVC also make extensive use of XML. The problem with this is compile time errors now only become apparent at runtime. Also writing and maintaining large volumes of XML is more difficult than Java code. The Java IDE refactoring tools are much more sophisticated than the XML tools available.

Click enables you to apply Object Oriented design principles such as subclassing to extend other Controls, or aggregation to build more sophisticated UI components. For example the Click control CreditCardField "is a" subclass of TextField and "has a" Select control for specifying the card type.

4.  Velocity

#if (!$session.order.lineItems.empty)
<table>
  <tr>
    <th>Name</th> <th>Quantity</th> <th>Total Price</th>
  </tr>
  #foreach ($lineItem in $session.order.lineItems)
  <tr>
    <td>$lineItem.name</td> 
    <td>$lineItem.quantity</td>   
    <td>$lineItem.totalPrice</td>   
  </tr>
  #end
</table>
#else
  No items have been ordered.
#end 

The one tricky part of Velocity, configuration is handled automatically by Click.

Please note that Click's template service is pluggable so you can also use Freemarker or JSPs for rendering in Click. It should be said that JSP 2.0 and the JSP Expression Language has improved the usability of JSP in recent years.