Java Web Application Development With Click Framework/Why Click

From Wikibooks, open books for an open world
Jump to navigation Jump to search

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

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

Simple to Learn[edit | edit source]

Click is designed to be simple learn so that new developers can get up and running in a day. This is very important with commercial development teams where you have a wide range of skill levels and motivation.

My experience introducing Tapestry (2.3) to development teams was that it is too complex and difficult to learn for the average developer. The two development teams I introduced to Tapestry eventually dropped it and revert to Struts.

Click is also significantly easier to learn than Struts. The Struts framework, while essentially a simple command pattern design, has quite a convoluted and confusing design.

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

Component and Page Oriented Design[edit | edit source]

If you have done traditional GUI programming with Swing, VB or Delphi you will know that there is something very wrong with JEE web development. JEE web development is painfully slow, complex and error prone.

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 working with primitive ActionForms. Its not giving you much leverage at all.

Tapestry was one of first the component base JEE web frameworks, introducing the 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 in 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 an 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.

JSP & MVC Free[edit | edit source]

Click is JSP and MVC Free. This is a good thing!

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 converted, 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 
    public ActionLink myLink = new ActionLink(this, "onClick");

    public boolean onClick() 
        System.out.println("onClick invoked");
        return true;

We include our myLink ActionLink control in the HTML page template:

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

At runtime the control href attribute renders as:

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

If the user clicks the link, the ActionLink control then invokes the invokes the Page's onClick() method.

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 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

In development of large applications this becomes a volumous, tedious and error prone task.

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.

Velocity[edit | edit source]

For rendering HTML Click uses the Velocity templating engine. Velocity has a simple instruction set which is very easy to learn and use. For example take a look at the template below.

#if (!$session.order.lineItems.empty)
    <th>Name</th> <th>Quantity</th> <th>Total Price</th>
  #foreach ($lineItem in $session.order.lineItems)
  No items have been ordered.

You should have a pretty good idea of what this code does without having to consult any taglib documentation. Velocity's ease of use made it the ideal choice for Click.

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

Please note you can also use 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.

Further reading[edit | edit source]

More Tutorials :