Page History

...

So, when the search form is submitted, the resulting search hits are collected. In the same request, the searchResults block is rendered, package, and sent to the client. The form inside the client-side Zone <div> is replaced with the list of hits.

In many cases, you just want to re-render the Zone itself, to display updated content. In that case, you don't need a seperate <t:block>, instead you can use @InjectComponent to inject the Zone object itself, and return the Zone's body:

  @InjectComponent
  private Zone statusZone;

  Object onActionFromUpdateStatus()
  {
    return statusZone.getBody();
  }

How to I update multiple zones in a single event handler?

To do this, you must know, on the server, the client ids of each Zone. That's one of the reasons that you will generally set the Zone's
client id (via the Zone.'s id parameter), rather than let Tapestry assign a client id for you.

From the event handler method, instead Instead of returning a Block or a Component, return a multi-zone update:

...

What's happening here is that Tapestry is working to prevent unwanted id clashes as part of the page update. In an HTML document, each id is
expected to be unique; most JavaScript is keyed off of the id field, for instance.

...

When the component is rendered as part of an Ajax partial page update, the rules are different. Since Tapestry doesn't know what content has been
rendered onto the page previously, it can't use its normal tricks to ensure that ids are unique.

...