Page History

...

  @Inject
  private Block searchResults;

  @Inject
  private Block statusBlock;

  Object onSuccessFromSearchForm()
  {
    searchHits = searchService.performSearch(query);

    message = String.format("Found %,d matching documents", searchHits.size());

    return new MultiZoneUpdate("results", searchResults).add("status", statusBlock);
  }

What's that weird number in the middle of the client ids after a Zone is updated?

You might start with markup in your template for a component such as a TextField:

  <t:textfield t:id="firstName"/>

When the component initially renders as part of a full page render, you get a sensible
bit of markup:

  <input id="firstName" name="firstName" type="text">

But when the form is inside a Zone and rendered as part of a zone update, the ids get weird:

   <input id="firstName_12a820cc40e" name="firstName" type="text">

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.

In a full page render, components don't just use their component id (t:id) as their client id; instead they use the JavaScriptSupport environmental to allocate a unique id. When there's no loops or conflicts, the client id matches the component id.

When the component is inside a loop, a suffix is appended: firstName, firstName_0, firstName_1, etc.

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 is normal tricks to ensure that ids are unique.

Instead, Tapestry creates a random-ish unique id suffix, such as "12a820cc40e" in the example; this suffix is appended to all allocated ids to ensure that they do not conflict with previously rendered ids.