Click can support multiple pages elements to enable the automapping of multiple packages.

<click-app>

  <pages package="com.mycorp.banking.page"/>

  <pages package="com.mycorp.common.page"/>

</click-app>

With multiple pages elements, pages are loaded in the order of the page elements, with manual page elements being loaded before automapped pages. Once a page template has been mapped to a Page class it will not be replaced by a subsequent potential match. So pages elements at the top take priority over lower pages elements.

Page automapping will automatically configure application pages using a simple set of rules. This enables you to greatly streamline your configuration file as you only need to define pages which don't fit the automapping rules.

Automapping will attempt to associate each page template (*.htm) and JSP file in the web application (excluding those under the WEB-INF and click directories) to a Page class. Automapped pages are loaded after the manually defined pages are loaded, and manually defined pages takes preference. When automapping is enabled the Click application will log the page mappings when in debug or trace mode.

For example, given the following page path to class mapping:

The above mapping could be configured manually by setting the automapping attribute to "false" and using the package prefix, for example:

<click-app>
  <pages package="com.mycorp.page" automapping="false">
    <page path="index.htm"                    classname="Home"/>
    <page path="search.htm"                   classname="Search"/>
    <page path="contacts/contacts.htm"        classname="contacts.Contacts"/>
    <page path="security/login.htm"           classname="security.Login"/>
    <page path="security/logout.htm"          classname="security.Logout"/>
    <page path="security/change-password.htm" classname="security.ChangePassword"/>
  </pages>
</click-app>

By using automapping the page paths will automatically map to page classes: (except for Home page which doesn't automatically map to index.html)

<click-app>
  <pages package="com.mycorp.page" automapping="true">
    <page path="index.htm" classname="Home"/>
  </pages>
</click-app>

Note automapping is true by default, so it could be omitted from the configuration file.

The page template name to classname convention is:

When automapping pages, if a class cannot be found Click will attempt to add the 'Page' suffix to the classname if not already present and map this. For example:

With Page automapping there can be resources where you don't want automapping applied. For example when using a JavaScript library with lots of .htm files, you don't want automapping to try and find Page class for each of these files. In these situations you can use the pages excludes element.

For example if our application uses the TinyMCE JavaScript library we could configure our pages automapping to exclude all .htm files under the /tiny_mce directory.

<click-app>
  <pages package="com.mycorp.page">
    <excludes pattern="/tiny_mce/*"/>
  </pages>
</click-app>

The excludes pattern can specify multiple directories or files using a comma separated notation. For example:

<click-app>
  <pages package="com.mycorp.page">
    <excludes pattern="/dhtml/*, /tiny_mce/*, banner.htm, about.htm"/>
  </pages>
</click-app>

HTM files excluded from Page automapping are handled by an internal Page class with caching headers enabled.

By default all pages have autobinding enabled. With autobinding the ClickServlet will automatically:

For example:

public class EmployeePage extends Page {

    public Form employeeForm = new Form();

    public Table myTable = new Table();

}

In the example above the employeeForm and myTable controls were not added to the page. Also note that Form and Table do not have their names defined.

When autobinding is enabled, ClickServlet will create a new Page and add the public controls to the page. In the example above the employeeForm and myTable will be added to the page, as if you had invoked, addControl(employeeForm) and addControl(myTable).

The control's names were not defined so ClickServlet will set their names to the value of their field/variable name. In this case the Form name will be set to employeeForm while the Table name will set to myTable.

The above example is thus a shorthand way of writing the following:

public class EmployeePage extends Page {

    private Form employeeForm = new Form();

    private Table myTable = new Table();

    public void onInit() {
        employeeForm.setName("employeeForm");
        addControl(employeeForm);

        myTable.setName("myTable");
        addControl(myTable);
    }
}

You can turn this behaviour off by setting the autobinding attribute to false, for example:

<click-app>
  <pages package="com.mycorp.page" autobinding="false"/>
</click-app>

Click provides the Bindable annotation which enables autobinding of Page fields. The Bindable annotation can bind private, protected and public Page fields. However by default, Click's autobinding feature operates only on public fields. The reason for this is keeping backwards compatibility with earlier versions which did not support the Bindable annotation.

To enable Click to recognize the @Bindable annotation you need to set the autobinding attribute to annotation, for example:

<click-app>
  <pages package="com.mycorp.page" autobinding="annotation"/>
</click-app>

You can now use the @Bindable annotation in your Pages:

public class EmployeePage extends Page {

    @Bindable protected Form employeeForm = new Form();

    @Bindable protected Table myTable = new Table();

}

Headers are typically used to switch off browser caching. By default Click will use the following no caching header values if you don't define a headers element in your application:

<click-app>
  <pages>
     ..
  </pages>
  <headers>
    <header name="Pragma" value="no-cache"/>
    <header name="Cache-Control"
            value="no-store, no-cache, must-revalidate, post-check=0, pre-check=0"/>
    <header name="Expires" value="1" type="Date"/>
  </headers>
</click-app>

Alternatively you can define your headers individually in pages or for all application pages by setting header values. For example to switch off caching in the login page, note the value for a Date type should be a long number value:

<pages package="com.mycorp.page">
  <page path="login.htm" classname="Login">
    <header name="Pragma" value="no-cache"/>
    <header name="Expires" value="1" type="Date"/>
  </page>
</pages>

If you wanted to enable caching for a particular page you could set the following page cache control header. This will mark the page as cachable for a period of 1 hour after which it should be reloaded.

<pages package="com.mycorp.page">
  <page path="home.htm" classname="Home">
    <header name="Cache-Control" value="max-age=3600, public, must-revalidate"/>
  </page>
</pages>

To apply header values globally define header values in the headers element. For example:

<click-app>
  <pages>
     ..
  </pages>
  <headers>
    <header name="Pragma" value="no-cache"/>
    <header name="Cache-Control"
               value="no-store, no-cache, must-revalidate, post-check=0, pre-check=0"/>
    <header name="Expires" value="1" type="Date"/>
  </headers>
</click-app>

When Page Auto Loading is enabled any new page templates and classes will be automatically loaded at runtime. These pages are loaded using the Page Automapping rules.

Page auto loading is a very handy feature for rapid development as you do not have to restart you application server to pick up new pages.

The Click and Velocity runtimes use LogService for logging messages. The default LogService implementation is ConsoleLogService which will send messages to the console [System.out]. For example the following logging output is for a HomePage request when the application mode is trace:

Any unhandled Throwable errors are logged by the ClickServlet.

Note that Click Extras also provide log adaptors for Log4J and the JDK Logging API.

When an application is not in production mode the error page displays detailed debugging information. When the application mode is production no debug information is displayed to prevent sensitive information being revealed. This behaviour can be changed by modifying the deployed click/error.htm page template.