The direct service is used to trigger a particular action. This service is tied to the DirectLink component. The service context identifies the page and component within the page. Any parameters specified by the DirectLink component's context parameter are encoded as well.

The request cycle for the direct service is more complicated that the page service.

Figure 6.2. Direct Service Sequence

As with the page service, the page involved has a chance validate the request. The component is located within the page, and the page is set as the default response page. The listener is free to override this, and can load other pages, change their properties, or otherwise affect the state of the application.

After the listener has its chance to respond to the request, a response page is renderred.

	IDirect vs. DirectLink
	The sequence shown above is for the DirectLink component, which implements the IDirect interface. In some rare cases, it is desirable to have a different component implement the IDirect interface instead. It will still implement the trigger() method, but will respond in its own way, likely without a listener.

This is the primary way (besides forms) in which applications respond to the user. What's key is the component's listener, of type IActionListener. This is the hook that allows pre-defined cotheirponents from the Tapestry framework to access application specific behavior. The page or container of the DirectLink component provides the necessary listener objects using dynamic bindings.

The direct service is useful in many cases, but does have its limitations. The state of the page when the listener is invoked is its state just prior to rendering (in the previous request cycle). This can cause a problem when the action to be performed is reliant on state that changes during the rendering of the page. In those cases, the action service (and ActionLink or Form components) should be used.

The DirectLink component has an optional parameter named parameters. The value for this may be a single object, an array of objects, or a List. Each object is converted into a string encoding, that is included in the URL. When the action is triggered, the array is reconstructed (from the URL) and stored in the IRequestCycle, where it is available to the listener. The type is maintained, thus if the third parameter is of type Integer when the URL is generated, then the third parameter will still be an Integer when the listener method is invoked.

This is a very powerful feature of Tapestry, as it allows the developer to encode dynamic page state directly into the URL when doing so is not compatible with the action service (described in the next section).

The most common use for these service parameters is to record an identifier for some object that is affected by the link. For example, if the link is designed to remove an item from the shopping cart (in an e-commerce example), the service parameters could identify which item to remove in terms of a primary key, or line number within the order.