In Click, a logical page is composed of a Java class and a Velocity template, with these components being defined in page elements of the click.xml file.
<page path="search.htm" classname="com.mycorp.page.Search"/>The path attribute specifies the location of the page Velocity template, and the classname attribute specifies the page Java class name. Alternatively you can also configure Click to use JSP pages for rendering.
<page path="search.jsp" classname="com.mycorp.page.Search"/>
Figure 1. Page Class Diagram - created with Enterprise Architect courtesy Sparx Systems
The Page class provides a model attribute which is used to hold all the objects that are rendered in the page's Velocity template. The model may also contain Control objects, which provide user interface controls on the Page. Pages also have an associated Context object which references all the javax.servlet objects associated with the request. When programming in Click you use the Context object to access HttpServletRequest attributes, parameters and the HttpSession object. The Page class provide a number of empty handler methods which subclasses can override to provide functionality: The ClickServlet relies on instantiating Pages using a public no arguments constructor, so when you create Page subclasses you must ensure you don't add an incompatible constructor.Figure 2. GET Request Sequence Diagram - created with Enterprise Architect courtesy Sparx Systems
Stepping through this GET request sequence, a new Page instance is created and the attributes for the Page are set (context, format, headers, path). Next the onInit() method is invoked, this is where you place any initialization code which requires access to the Context. The next method invoked is the onSecurityCheck() handler. This method can used to ensure the user is authorized to access the page, and if necessary can abort any further processing. The next step is the processing of the Page's controls. The ClickSerlvet gets the list of Controls from the page and then iterates through the list calling onProcess(). If any of the Control's onProcess() methods return false, processing of subsequent controls and the Page's onGet() method is aborted. If everything is executing normally the Page's onGet() method is now called. The next step is rendering the page template to generate the displayed HTML. The ClickServlet gets the model (Map) from the Page then adds the following objects to the model:Figure 3. Page Execution Activity Diagram - created with Enterprise Architect courtesy Sparx Systems
/** * @see Page#onPost() */ public void onPost() { // Process form post .. setForward("index.htm"); }This will invoke a new Page class instance mapped to the path index.htm. Note when a request is forwarded to another Page, the controls on the second page will not be processed. This prevents confusion and bugs, like a form on the second page trying to process a POST request from the first page.
public boolean onViewClick() { Long id = viewLink.getValueLong(); Customer customer = CustomerDAO.findByPK(id); getContext().setRequestAttribute("customer", customer); setForward("view-customer.htm"); return false; }Forwarded to page template view-customer.htm:
<html> <head> <title>Customer Details</title> </head> <body> <h1>Customer Details</h1> <pre> Full Name: $customer.fullName Email: $customer.email Telephone: $customer.telephone </pre> </body> </html>Request attributes are automatically added to the Velocity Context object so are available in the page template.
public boolean onEditClick() { Long id = viewLink.getValueLong(); Customer customer = CustomerDAO.findByPK(id); EditPage editPage = (EditPage) getContext().createPage("/edit-customer.htm"); editPage.setCustomer(customer); setForward(editPage); return false; }When creating a page with the createPage() method ensure you prefix the page path with the "/" character. You can also specify the target page using its class as long as the Page has a unique path. Using this technique the above code becomes:
public boolean onEditClick() { Long id = viewLink.getValueLong(); Customer customer = CustomerDAO.findByPK(id); EditPage editPage = (EditPage) getContext().createPage(EditPage.class); editPage.setCustomer(customer); setForward(editPage); return false; }This Page forwarding technique is best practice as it provides you with compile time safety and alleviates you from having to specify page paths in your code. Please always use the Context createPage() methods to allow Click to inject Page dependencies.
public boolean onViewClick() { Long id = viewLink.getValueLong(); Customer customer = CustomerDAO.findByPK(id); addModel("customer", customer); setPath("view-customer.htm"); return false; }Note how the customer object is passed through to the template in the Page model. This approach of using the Page model is not available when you forward to another Page, as the first Page object is "destroyed" before the second Page object is created and any model values would be lost.
public boolean onLogoutClick() { setRedirect("/logout.htm"); return false; }If the redirect location is begins with a "/" character the redirect location will be prefixed with the web applications context path. For example if an application is deployed to the context "mycorp" calling setRedirect( ) will redirect the request to: "/mycorp/customer/details.htm" You can also obtain the redirect path via the target Page's class. For example:
public boolean onLogoutClick() { String path = getContext().getPagePath(Logout.class); setRedirect(path); return false; }Note when using this redirect method, the target Page class must have a unique path. A short hand way of redirecting is to simply specify the target Page class in the redirect method. For example:
public boolean onLogoutClick() { setRedirect(Logout.class); return false; }
public class Payment extends Page { .. public boolean onOkClick() { if (form.isValid()) { // Process payment .. // Get transaction id Long transId = OrderDAO.purchase(order); setRedirect("trans-complete.htm?transId=" + transId); return false; } return true; } }The Page class for the trans-complete.htm page can then get the transaction id through the request parameter "transId":
public class TransComplete extends Page { /** * @see Page#onInit() */ public void onInit() { String transId = getContext().getRequest().getParameter("transId"); if (transId != null) { // Get order details Order order = OrderDAO.findOrderByPK(new Long(transId)); if (order != null) { addModel("order", order); } } } }
public class BorderedPage extends Page { /** * @see Page#getTemplate() */ public String getTemplate() { return "border.htm"; } }The BorderedPage template border.htm:
<html> <head> <title>$title</title> <link rel="stylesheet" type="text/css" href="style.css" title="Style"/> </head> <body> <h2 class="title">$title</h2> #parse($path) </body> </html>Other pages insert their content into this template using the Velocity #parse directive, passing it their contents pages path. The $path value is automatically added to the VelocityContext by the ClickServlet. An example bordered Home page is provided below:
<page path="home.htm" classname="Home"/>
public class Home extends BorderedPage { public Home() { addModel("title", "Home"); } }The Home page's content home.htm:
<b>Welcome</b> to Home page your starting point for the application.When a request is made for the Home page (home.htm) Velocity will merge the border.htm page and home.htm page together returning:
<html> <head> <title>Home</title> <link rel="stylesheet" type="text/css" href="style.css" title="Style"/> </head> <body> <h2 class="title">Home</h2> <b>Welcome</b> to Home page your application starting point. </body> </html>Which may be rendered:
HomeWelcome to Home page your application starting point. |
public class Secure extends Page { /** * @see Page#onSecurityCheck() */ public boolean onSecurityCheck() { if (getContext().hasSession()) { return true; } else ( setRedirect("login.htm"); return false; } } }
public class Secure extends Page { /** * @see Page#onSecurityCheck() */ public boolean onSecurityCheck() { if (getContext().getRequest().getRemoteUser() != null) { return true; } else ( setRedirect("login.htm"); return false; } } }
public class AdminPage extends Page { /** * @see Page#onSecurityCheck() */ public boolean onSecurityCheck() { if (getContext().getRequest().isUserInRole("admin")) { return true; } else ( setRedirect("login.htm"); return false; } } }
public class Logout extends Page { /** * @see Page#onInit() */ public boolean onInit() { getContext().getSession().invalidate(); } }
<page path="click/error.htm" classname="net.sf.click.util.ErrorPage"/>To register an alternative error handler you must subclass ErrorPage and define your page using the path "click/error.htm". For example:
<page path="click/error.htm" classname="com.mycorp.page.ErrorPage"/>When the ClickSevlet starts up it checks to see whether the error.htm template exists in the click web sub directory. If it cannot find the page the ClickServlet will automatically deploy one. You can tailor the click/error.htm template to suite you own tastes, and the ClickServlet will not overwrite it. The default error template will display extensive debug information when the application is in development or debug mode. Example error page displays include:
<page path="click/not-found.htm" classname="net.sf.click.Page"/>You can override the default configuration and specify your own class, but you cannot change the path. When the ClickSevlet starts up it checks to see whether the not-found.htm template exists in the click web sub directory. If it cannot find the page the ClickServlet will automatically deploy one. You can tailor the click/not-found.htm template to suite you own needs. This page template has access to the usual Click objects.
<h1> $messages.title </h1>This messages map is loaded from the page classes property bundle. For example if you had a page class com.mycorp.page.CustomerList you could have an associated property file containing the pages localized messages:
/com/mycorp/page/CustomerList.propertiesYou can also defined a application global page messages properties file:
/click-page.propertiesMessages defined in this file will be available to all pages through out your application. Note messages defined in your page class properties file will override any messages defined in the application global page properties file. Page messages can also be used to override Control messages, see the Controls Message Properties topic for more details.