Engines, services and friends

Tapestry has evolved its own jargon over time.

The Engine is a central object, it occupies the same semantic space in Tapestry that the HttpSession does in the Servlet API. The Engine is ultimately responsible for storing the persistent state of the application (properties that exist from one request to the next), and this is accomplished by storing the Engine into the HttpSession. This document will largely discuss the default implementation, with notes about how the default implementation may be extended or overriden, where appropriate.

Engine services are the bridge between servlets and URLs and the rest of Tapestry. Engine services are responsible for encoding URLs, providing query parameters that identify, to the framework, the exact operation that should occur when the generated URL is triggered (by the end user clicking a link or submitting a form). Services are also responsible for dispatching those incoming requests. This encapsulation of URL encoding and decoding inside a single object is key to how Tapestry components can flexibily operate without concern for how they are contained and on which page ... the services take into account page and location when formulating URLs.

The Visit object is an application-defined object that acts as a focal point for all server-side state (not associated with any single page). Individual applications define for themselves the class of the Visit object. The Visit is stored as a property of the Engine, and so is ultimately stored persistently in the HttpSession

The Global object is also application-specific. It stores information global to the entire application, independent of any particular user or session. A common use for the Global object is to centralize logic that performs JNDI lookups of session EJBs.