When a Zone component sends an Ajax request for a client-side update, it should pass an extra query parameter identifying the zone's client-side id

Details

Description

It's somewhat common to render new content that, itself, will want to be able to update the same zone, but the client-side id can't be recalculated on the server side due to the nature of rendering and id allocation. Thus, the only way for the server side to know what the client-side id is, is for the client-side to pass that information along.

In my case, I'm working on a dynamic edit component that shows some content, with a link to switch to edit mode. Clicking the link updates the Zone with a form. Submitting the form needs to return the component back to its initial output-only state (but with the new content). At each step, the id of the Zone needs to be passed along so that the form, or output content, can render the correct content.

The catch is that when you specify the zone id to action or event links, the id is the client id, not the tapestry id. But this gets obscured, because since the client id isn't set on the zone, tapestry uses "myzone" for the first zone, and "secondzone_RANDOM" for the id of the nested zone.

Meanwhile, the JSON that is generated for doing the ajax links says:

zoneId = "secondzone";

which then doesn't work because it doesn't match the id on the client side, which has RANDOM appended.

Pierce Wetter
added a comment - 17/Aug/10 21:16 So there's a gotcha if you do:
<t:zone t:id="myzone">
<t:actionlink zone="myzone" t:id="updateMyZone">Click Me</t:actionlink>
</t:zone>
<t:block>
<t:zone t:id="secondzone" />
<t:actionlink zone="secondzone" t:id="updateMyZoneASecondTime">Click Me</t:actionlink>
</t:block>
i.e. nested, chained, zones
The catch is that when you specify the zone id to action or event links, the id is the client id, not the tapestry id. But this gets obscured, because since the client id isn't set on the zone, tapestry uses "myzone" for the first zone, and "secondzone_RANDOM" for the id of the nested zone.
Meanwhile, the JSON that is generated for doing the ajax links says:
zoneId = "secondzone";
which then doesn't work because it doesn't match the id on the client side, which has RANDOM appended.
See: https://issues.apache.org/jira/browse/TAP5-893
I'm wondering if this change could be used to fix the above?