Tapestry 5
  1. Tapestry 5
  2. TAP5-108

A component event handler for Ajax requests should have a mechanism to update mutiple zones on the client

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.15
    • Fix Version/s: 5.1.0.1
    • Component/s: None
    • Labels:
      None

      Description

      Unfortunately the ActionLink's parameter "zone" expect a single zone. Commonly, we want to update several parts of the client. It would be very nice to be able to update a bunch of zones after an action was triggered. This limitation is quite frustrating for people coming from T4 because "updateComponents" expected a list of component ids.

        Activity

        Hide
        Howard M. Lewis Ship added a comment -

        Thiago – we are thinking alike; the new behavior is triggered by a return type of MultiZoneUpdate (which is kind of like a typed Map of string and Renderable/Block/RenderCommand/whatever).

        Show
        Howard M. Lewis Ship added a comment - Thiago – we are thinking alike; the new behavior is triggered by a return type of MultiZoneUpdate (which is kind of like a typed Map of string and Renderable/Block/RenderCommand/whatever).
        Hide
        Joost Schouten added a comment -

        Just to share a thought: I build a MultipleZoneUpdater Mixin which has been doing the job nicely for a while now. I just do everything the normal way, but Mix-in my Mixin on a component that contains the trigger that needs to update extra zone's and the zone's that need to be updated.

        From the parameters below you can understand the way I use it. If intrested I can add the whole code and js file later. What I really like about it is that it Allows an easy way to wire up any block to any zone on any js event. In the case you wire it up to a Zone,the other zones will update once that one is done, which is needed beacause often you want a CRUD action to be completed before another zone is updated.

        Anyway, just my 2 cents.

        /**

        • A Map of Zone id's mapped to the Block id's to update the zone
          */
          @Parameter(required = true)
          private Map<String, String> zoneBlocks;

        /**

        • A comma seperated list of css identifiers of all elements that should trigger the
        • multiple zone update. All identifiers will update all passed zoneBlocks
        • in case of an a: onmouseup
        • in case of a zone: once loaded
        • in case of a form: onsubmit
          */
          @Property
          @Parameter(required = true, defaultPrefix = "literal")
          private String zoneTriggerCssIdentifiers;
        Show
        Joost Schouten added a comment - Just to share a thought: I build a MultipleZoneUpdater Mixin which has been doing the job nicely for a while now. I just do everything the normal way, but Mix-in my Mixin on a component that contains the trigger that needs to update extra zone's and the zone's that need to be updated. From the parameters below you can understand the way I use it. If intrested I can add the whole code and js file later. What I really like about it is that it Allows an easy way to wire up any block to any zone on any js event. In the case you wire it up to a Zone,the other zones will update once that one is done, which is needed beacause often you want a CRUD action to be completed before another zone is updated. Anyway, just my 2 cents. /** A Map of Zone id's mapped to the Block id's to update the zone */ @Parameter(required = true) private Map<String, String> zoneBlocks; /** A comma seperated list of css identifiers of all elements that should trigger the multiple zone update. All identifiers will update all passed zoneBlocks in case of an a: onmouseup in case of a zone: once loaded in case of a form: onsubmit */ @Property @Parameter(required = true, defaultPrefix = "literal") private String zoneTriggerCssIdentifiers;
        Hide
        Thiago H. de Paula Figueiredo added a comment -

        What if any event handler method that can return a Zone or Block could also receive a <zone id, block or zone to render> map? Not only ActionLink, but also EventLink, Form, etc. This would be very T5-ish (contrasted with T4's updateComponents) and could be implemented only changing Tapestry internal services, without breaking existing code.

        Show
        Thiago H. de Paula Figueiredo added a comment - What if any event handler method that can return a Zone or Block could also receive a <zone id, block or zone to render> map? Not only ActionLink, but also EventLink, Form, etc. This would be very T5-ish (contrasted with T4's updateComponents) and could be implemented only changing Tapestry internal services, without breaking existing code.
        Hide
        Thiago H. de Paula Figueiredo added a comment -

        I think this issue could be also applied for forms and any other component that can trigger an event.
        Howard, how would Tapestry know what needs to be updated? I didn't get you comment. Wouldn't the developer know better what needs to be updated? I really miss T4's AJAX flexibility in T5 (multiple places to be updated).

        Show
        Thiago H. de Paula Figueiredo added a comment - I think this issue could be also applied for forms and any other component that can trigger an event. Howard, how would Tapestry know what needs to be updated? I didn't get you comment. Wouldn't the developer know better what needs to be updated? I really miss T4's AJAX flexibility in T5 (multiple places to be updated).
        Hide
        Renat Zubairov added a comment -

        Is it possible now to dynamically decide which zones will be updated? For example when form is sent as part of AJAX request then either "Errors" section will be updated or complete form will be replaced with something else?

        Show
        Renat Zubairov added a comment - Is it possible now to dynamically decide which zones will be updated? For example when form is sent as part of AJAX request then either "Errors" section will be updated or complete form will be replaced with something else?
        Hide
        Howard M. Lewis Ship added a comment -

        The current design is organized around minimizing the amount of configuration necessary, and to let the server side decide what gets updated and how.

        Show
        Howard M. Lewis Ship added a comment - The current design is organized around minimizing the amount of configuration necessary, and to let the server side decide what gets updated and how.
        Hide
        Davor Hrg added a comment -

        just some thoughts... :

        some parts of the page require the page to be processed so a zone around that part can be properly rendered.
        however, tickers, chat messages, updateable statuses may be independent of the rest of the page,
        zone should assume the component is dependent, and process the page normally,
        and have a parameter with which we can say: "this zone is independent"

        Show
        Davor Hrg added a comment - just some thoughts... : some parts of the page require the page to be processed so a zone around that part can be properly rendered. however, tickers, chat messages, updateable statuses may be independent of the rest of the page, zone should assume the component is dependent, and process the page normally, and have a parameter with which we can say: "this zone is independent"
        Hide
        Renat Zubairov added a comment -

        It would be also very nice to be able to define zones for update dynamically. As it is done in T4 we can dynamically decide which zones to update. We've developed a kind of framework on top of T4 where each component in processing/creation of event can decide wherever to update itself or not.

        Typical example of the use-case is login dialog implemented via Dojo dialog or similar modal dialogs, when user authenticate itself then some of the components on the page may decide to re-render themself.

        That would make even more sense with event bulbing in T5.

        Show
        Renat Zubairov added a comment - It would be also very nice to be able to define zones for update dynamically. As it is done in T4 we can dynamically decide which zones to update. We've developed a kind of framework on top of T4 where each component in processing/creation of event can decide wherever to update itself or not. Typical example of the use-case is login dialog implemented via Dojo dialog or similar modal dialogs, when user authenticate itself then some of the components on the page may decide to re-render themself. That would make even more sense with event bulbing in T5.

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Igor Drobiazko
          • Votes:
            28 Vote for this issue
            Watchers:
            14 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development