Advanced Features of the Tapestry Framework, Page 2
To tell Tapestry framework which object it should use as a Visit object, the application specification file needs to have the "visit-class" property:
<b><property name="org.apache.tapestry.visit-class"> com.myapp.Visit </property>
In addition to the visit object concept, developers need to know some main interfaces such as IRequestCycle and IMarkupWriter. The IRequestCycle interface provides easy access to the controller object that manages a single request cycle. A request cycle is one 'hit' on the Web server. More importantly, it provides access to Tapestry's rendering pipeline and IEngineService object.
"A request cycle is broken up into two phases. The rewind phase is optional, as it is tied to ActionLink or Form components. In the rewind phase, a previous page render is redone (discarding output) until a specific component of the page is reached. This rewinding ensures that the page is restored to the exact state it had when the URL for the request cycle was generated, taking into account the dynamic nature of the page (Foreach, Conditional, etc.). Once this component is reached, it can notify its IActionListener. The listener has the ability to update the state of any pages and select a new result page."
The IMarkupWriter interface defines an object that can write markup (XML, HTML, or XHTML) style output. A IMarkupWriter handles translation from Unicode to the markup language as well as assisting with nested elements and closing tags.
IComponent represents a component that renders an HTML element on the page and IAsset represents an asset such as an image (GIF, JPEG, and so forth) that may be owned by an IComponent.
There are many more interfaces that are very useful in the Tapestry application, but they are beyond the scope of this article. You can look though API documentation to learn about the rest of them.
Exception Handling and Logging
Tapestry has an extremely sophisticated exception reporting and logging mechanism. The Exception reporting uses reflection to work backwards through the chain of exceptions, displaying JavaBeans properties of each exception and a stack trace of the deepest exception.
In addition, a wealth of detail about the servlet, application, request, servlet context, and JVM is displayed. The goal is to save developers debugging time by producing a complete report when exceptions do occur.
The look and feel of the exception reporting page can be customized per application.
Here is a snapshot of the wealth of output produced when an error occurs. This is only a small portion of the output from the JVM, and you can see the entire output included with the source code.
Generic Components and Features
As I mentioned, one of the great strengths of the Tapestry framework is its component-based architecture. It comes with many pre-built components; in addition, if you find that something is missing or need some custom component, all you need to do is write it and it will be reusable in other applications. To use any component, its XML specification needs to be added to the page specification file. For example, in addition to all the generic components ,such as, form, button, text field, and so on, Tapestry also has Request Forwarding, Field validation, Localization and Internalization, Calendar and Date, drop-down box, and any other extra components. Here is how you would add a drop-down box component to a page.
<page-specification class="com.somepackage.SomePage"> .... <component id="dropDownBox" type="PropertySelection"> <binding name="model" value="someValues"/> <binding name="value" value="valueId"/> </component> </page-specification>
Or to use Calendar, you'd only need to add:
<component id="someDate" type="<b>DatePicker"> <binding name="value" value="someDate"/> </component>
The sample project builds upon the example from Part One and takes advantage of the some of the more advanced built-in features of the framework. Because Tapestry is a very advanced framework and offers a lot of pre-packaged functionality, the sample project will only show basic data flow. I will leave it up to the readers to explore the excellent API documentation provided with the framework (and also available online at http://jakarta.apache.org/tapestry/3.0.3/doc/api/index.html) to learn about the rest of the components.
I am assuming that you have set up the development environment as described in the first part and feel comfortable deploying Web applications on the application server. To run the application, unzip it into some directory and use the provided WAR file to deploy it on WebLogic.
In this article, I have covered some of the more advanced aspects of the Tapestry framework for Web development. I have expanded the sample project from the first part and built it into a real working application using some of the most popular and useful features of the framework.
Tapestry may not be for everyone because of its complexity and abundance of APIs, modules, and pre-packaged components. Its learning curve is definitely one of the longest comparing with the other frameworks, and its development style is fundamentally different from the other frameworks as well, but it certainly can be very rewarding if you put some time into it. If utilized properly, Tapestry can definitely shorten the development circle and reduce amount of coding in a Web application.
As a next step, I recommend looking at the online resources such as the Tapestry online tutorial and picking up any book about the framework.
You can download the source code for this sample here. Compiling the sample requires Tapestry framework libraries. You can download those at http://jakarta.apache.org/site/downloads/downloads_tapestry.cgi. Extract them into the lib folder under the JBuilder project.
- Wikipedia online: http://en.wikipedia.org/wiki/
- Tapestry: http://jakarta.apache.org/tapestry/
- Tapestry online tutorial
- Art of Java Web Development: Struts, Tapestry, Commons, Velocity, JUnit, Axis, Cocoon, InternetBeans, WebWork (Paperback) by Neal Ford,ISBN: 1932394060
Appendix A: Compete Tapestry Package List
About the Author
Vlad Kofman is a Senior System Architect working on projects under government defense contracts. He also has been involved with enterprise-level projects for major Wall Street firms and the U.S. government. His main interests are object-oriented programming methodologies and design patterns.