Tapestry 5
  1. Tapestry 5
  2. TAP5-1061

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

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.2.0
    • Fix Version/s: 5.2.0
    • Component/s: tapestry-core
    • Labels:
      None

      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.

        Activity

        Howard M. Lewis Ship created issue -
        Howard M. Lewis Ship made changes -
        Field Original Value New Value
        Assignee Howard M. Lewis Ship [ hlship ]
        Howard M. Lewis Ship made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Howard M. Lewis Ship made changes -
        Status In Progress [ 3 ] Closed [ 6 ]
        Fix Version/s 5.2.0 [ 12314122 ]
        Resolution Fixed [ 1 ]
        Hide
        Howard M. Lewis Ship added a comment -

        Also, made it easier to pass additional query parameters along when triggering a zone update

        Show
        Howard M. Lewis Ship added a comment - Also, made it easier to pass additional query parameters along when triggering a zone update
        Hide
        Pierce Wetter added a comment -

        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?

        Show
        Pierce Wetter added a comment - 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?

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Howard M. Lewis Ship
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development