An overview of Tapestry

Perhaps the hardest part of understanding Tapestry is the fact that it is component-centric not operation-centric. Most web technologies (Struts, servlets, PHP, etc.) are operation-centric. You create servlets (or Actions, or what have you) that are invoked when a user clicks a link or submits a form. You are responsible for selecting an appropriate URL, and the name and type of any query parameters, so that you can pass along the information you need in the URL.

You are also responsible for connecting your output pages (whether they are JSPs, Velocity templates, or some other form of templating technology) to those operations. This requires you to construct those URLs and get them into the href attribute of your <a> tag, or into the action attribute of your <form> tag.

Everything is different inside Tapestry. Tapestry applications consist of pages; pages are constructed from smaller components. Components may themselves be constructed from other components. Every page has a unique name, and every component within a page has its own unique id ... this is a component object model. Effectively, every component has an address that can easily be incorporated into a URL.

In practical terms, your don't write a servlet for the add-item-to-shopping-cart operation. In fact, you don't even write an add-item-to-shopping-cart component. What you do is take an existing component, such as DirectLink, and configure it. When the component renders, it will create a callback URL. When you click that link, the callback URL (which includes the name of the page and the id of the component within the page) will invoke a method on the component ... and that method invokes your application-specific listener method. [1] You supply just the listener method ... not an entire servlet. Tapestry takes care that your listener method is invoked at the right time, under the right conditions. You don't have to think about how to build that URL, what data goes in the URL, or how to hook it up to your application-specific code--that's all handled by the framework.

Figure 1.1. Tapestry request dispatch (high level)

Tapestry request dispatch (high level)

Tapestry uses a component object model to dispatch incoming requests to the correct page and component.



[1] Listener methods in Tapestry are very similar in intent to delegates in C#. In both cases, a method of a particular object instance is represented as an object. Calling this a "listener" or a "listener method" is a bit of a naming snafu; it should be called a "delegate" and a "delegate method" but the existing naming is too deeply entrenched to change any time soon.