In the first part of this article, I discussed the main structure of the Tapestry framework, as well as its setup and configuration in an enterprise scale development environment such as JBuilder 2005. In this article, I will further explore the features of the framework and discuss specific components and pre-build modules. A sample application that uses Tapestry is included for your reference as well.
Structure of the Framework
As discussed in the first part of the article, the Tapestry framework tries to hide all of the plumbing associated with coding a Web application by giving developers a solid API set that feels more like a desktop Graphical User Interface (GUI) or a Swing development toolkit. For instance, it is never necessary to write code to directly read HTTP parameters, or directly deal with session, request, response, JSPs, tags, and so forth.
Most modern Web frameworks come with pre-build modules to help with development process, simplify specific functions, or give developers more flexibility. Tapestry is no exception; in fact, it excels in this area. It comes with a cornucopia of pre-built modules that have all of their functionality working "out of the box." I will elaborate on this later. In addition to providing a lot of APIs for the developer, Tapestry provides whole modules that try to do the most common tasks found in the Web application, such as file upload, date/calendar logic, table pagination, field validation, internalization, redirection, and even popup functionality. Among some of the more advanced modules that also come as standard functionality of Tapestry are data trees and charts.
At the time of this writing, Tapestry is at version 4. The class and interface hierarchy are fully developed and the code is stable. Most components also are finalized and production quality. The code for the framework is combined into several logical packages, each corresponding to a specific functionality or feature.
Here is a short list of the most interesting packages provided by the framework. The complete list is available in the references section as Appendix A.
org.apache.tapestry
org.apache.tapestry.components
org.apache.tapestry.contrib.jdbc
org.apache.tapestry.contrib.link
org.apache.tapestry.contrib.popup
org.apache.tapestry.contrib.table.model
org.apache.tapestry.contrib.tree.model
org.apache.tapestry.engine
org.apache.tapestry.event
org.apache.tapestry.form
org.apache.tapestry.html
org.apache.tapestry.listener
org.apache.tapestry.multipart
org.apache.tapestry.valid
The main packages are org.apache.tapestry and org.apache.tapestry.engine. They represent the "brains" of the framework and expose public interfaces, as well as concrete implementation of them for the developers. The IEngine AbstractEngine and BaseEngine interfaces are located there.
The org.apache.tapestry.components package has "Basic, fundamental components used to construct more complex components, or pages," are very powerful objects that allow a lot flexibility. The org.apache.tapestry.contrib.jdbc, org.apache.tapestry.multipart, and org.apache.tapestry.wml are some of the packages that contain a lot of extra useful functionality. I mention them to show just how massive the framework is, and how the creators are trying to cover all possible aspects of the enterprise Web development. The org.apache.tapestry.listener and org.apache.tapestry.event packages have some of the classes that give Tapestry APIs resemblance to the GUI or Swing listener mechanism for the pages (and objects on them). Because all of the logic of the Web interface is hidden in Tapestry, these classes make it very easy to code events and actions based on them.
The org.apache.tapestry.contrib.link and org.apache.tapestry.contrib.popup are helper packages that encapsulate links and popup windows. The org.apache.tapestry.form package encapsulates HTML forms and treats all of the HTML elements of the form as objects, giving developers ability to add listeners or associate state with these elements. The org.apache.tapestry.valid package has some useful validation classes, such as EmailValidator or DateValidator. There is a public interface IValidator, but it was very thoughtful of the Tapestry creators to include a lot of pre-built validator objects. The org.apache.tapestry.html package has components specific to the creation of HTML pages, including sophisticated DHTML JavaScript effects. If you are familiar with the Swing toolkit, you will find some likeness in the package structures, in particular org.apache.tapestry.contrib.table.model and org.apache.tapestry.contrib.tree.model have model classes for the tree and the table components. The GUI classes that use these models are in org.apache.tapestry.contrib.table.components and org.apache.tapestry.contrib.tree.components packages. These components are very robust and have pre–built-in functionality that performs without any extra work; for example, the table has sorting and pagination capabilities.
I recommend that you explore the great API documentation that comes with Tapestry before plunging in and coding some feature. Chances are if the feature is generic, it may available be already.
Framework Components
Because Tapestry encapsulates Web APIs in the form of a component object model, all of the most common Web objects are available as objects to developers. Here is the complete list of some of the components that are available "out of the box" with the Tapestry framework. You can also find more information about each of these at the official Tapestry Web page.
Contrib Library
WML Library
High Level Interfaces and Data Flow
Developing in Tapestry requires not only using the provided components, learning the APIs, and XML component and page specification, but also understanding its main concepts and the logic flow of the framework.
There are several high-level concepts that developers need to know in order to use Tapestry successfully. One such conceptsis the Visit object. The Visit object holds information about a single client's visit to the Web page. This object is instantiated by the Engine and is maintained, serialized, and deserialized by it. This object can potentially be any custom object that implements a serializable interface and that is the only requirement; no other requirement is imposed. Under the hood, this object is stored persistently in the HttpSession.
Rethinking the Datacenter
Putting the Green into IT
Managing the Modern Network
Evaluating Software as a Service for Your Business
Is Your Disaster Recovery Plan Good Enough? 
IE 7
Firefox 2.0
