Page History

...

When a page has an activation context, the values of the context are appended to the URL path. For example, in http://www.example.com/myapp/foo/bar the "myapp" part is the servlet context (usually the name of your app), and the "foo/bar" part is the activation context, with "foo" being the first activation parameter and "bar" being the second.

It is common for most pages to not have any Not all pages have an activation context.

The activation context may be explicitly set when the render request link is created (the PageLink component has a context parameter for this purpose).

When no explicit activation context is provided, the page itself is queried for its activation context. This querying takes the form of an event trigger. The event name is "passivate" (as we'll see shortly, there's a corresponding "activate"). The return value of the method is used as the context. For example:

public class ProductDetail
{
  private Product product;

  . . .

  long onPassivate() { return product.getId(); }
}

...

A page's activate event handler mirrors its passivate handler:

  private Product product;
  . . .

  void onActivate(long productId)
  {
     product = productDAO.getById(productId);
  }

  . . .

Here's the relevant part: when the page renders, it is likely to include more component event request URLs (links and forms). The component event requests for those links and forms will also start by activating the page, before performing other work. This forms an unbroken chain of requests that include the same activation context.

To some degree, this same effect could be accomplished using a persistent page value, but that requires an active servlet session, and the result is not bookmarkable.

The Your activate event handler, like any event handler, may also return a value, which is treated identically to a return value of a component event method. This will typically be used in an technique is commonly used as a simple access validation scenariomechanism.

It is common to You sometimes need to handle multiple page activation scenarios in one page class. You can could create multiple activate event handler methods with different arguments (see the "Multiple Method Matches" section at Component Events for details), but if you do so, you should generally return true from each to avoid having more than one activation event handler method from being called for each page request. However, a better approach is to create one method with an EventContext argument. Tapestry will populate the EventContext argument with all of the activation parameters, and the EventContext's get method will retrieve and coerce each parameter to the desired type. For example:

  . . .

  void onActivate(EventContext eventContext) {

    String color = DEFAULT_COLOR;

    if (eventContext.getCount() > 0) {
      long productId = eventContext.get(Long.class, 0);

      if (eventContext.getCount() > 1) {
        String color = eventContext.get(String.class, 1);
      }
      product = productDAO.getById(productId, color);
    } else {
      return SelectProduct.class; // no product selected
    }
  }

  . . .

Page Navigation Patterns

...