Tapestry 5
  1. Tapestry 5
  2. TAP5-138

Add Zone parameter to Select component

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.15
    • Fix Version/s: 5.2.0, 5.1.0.6, 5.1.0.7
    • Component/s: None
    • Labels:
      None

      Description

      Add AJAX ability to selection in a Select component to allow the classic chaining of Select components.

      Eg. for filtering car advertisements: 3 Select components - Brand, Make, Model. Choosing a Brand causes the Make to be enabled, showing the possible makes. Similarly, choosing a Make causes the Model to be enabled, showing the possible models.

        Activity

        Hide
        Christian Riedel added a comment -

        Just saw some possible unnecessary injection. Looking at those two:

        Select.java line 113:

        @Inject
        private ComponentResources resources;

        and Select.java line 154:

        @Inject
        private ComponentResources componentResources;

        I think the second one could be omitted, right?

        Show
        Christian Riedel added a comment - Just saw some possible unnecessary injection. Looking at those two: Select.java line 113: @Inject private ComponentResources resources; and Select.java line 154: @Inject private ComponentResources componentResources; I think the second one could be omitted, right?
        Hide
        Joe Klecko added a comment -

        I think we all could definitely live with just a "pragmatic solution which works for the select component " and you would make a lot of people happy! I'm fine with having the simpler approach and waiting to see if more use cases come out. The nice thing about this approach, is that, if some one does need to bite the bullet and fix this at the framework level, it doesn't sound like it will break backwards compatibility (thank you tapestry5).

        Show
        Joe Klecko added a comment - I think we all could definitely live with just a "pragmatic solution which works for the select component " and you would make a lot of people happy! I'm fine with having the simpler approach and waiting to see if more use cases come out. The nice thing about this approach, is that, if some one does need to bite the bullet and fix this at the framework level, it doesn't sound like it will break backwards compatibility (thank you tapestry5).
        Hide
        Igor Drobiazko added a comment -

        Thank you for the comment.

        Implementing the option A is not a big deal. Since the whole form is updated there will be no exception about the missing FormSupport. But as I mentioned earlier I believe that option A is less often.

        Implementing option B is more tricky. In order to provide the FormSupport for the newly added select component one should put a PartialMarkupRendererFilter into the PageRenderQueue. This filter would create a FormSupport and push it into the environment. This is actually how FormInjector is working. However we need something similar as a mixin.

        I think we could live with a pragmatic solution which works for the select component instead of implementing a general solution. If there are more use cases in the feature we can think about a general mixin or what ever. What do you think?

        Show
        Igor Drobiazko added a comment - Thank you for the comment. Implementing the option A is not a big deal. Since the whole form is updated there will be no exception about the missing FormSupport. But as I mentioned earlier I believe that option A is less often. Implementing option B is more tricky. In order to provide the FormSupport for the newly added select component one should put a PartialMarkupRendererFilter into the PageRenderQueue. This filter would create a FormSupport and push it into the environment. This is actually how FormInjector is working. However we need something similar as a mixin. I think we could live with a pragmatic solution which works for the select component instead of implementing a general solution. If there are more use cases in the feature we can think about a general mixin or what ever. What do you think?
        Hide
        Joe Klecko added a comment -

        Since no one has responded and this is by far the most voted for jira issue I'll give it a go. IMHO this is a pretty big Ajax handicap for the framework, I will respond by saying that option B is the typical issue, but as you do bring up a good point, there shouldn't be any reason the select component cannot update any zone, which means the issue goes deeper than that and is actually a framework issue.

        The problem is that the framework does not allow any new form fields to be added via standard zone updates, so the ultimate solution is to fix this (if even possible) and implement option A. If the framework were to somehow know a zone is within a form and that zone is updated (regardless of which component updated the zone), any new fields should be appropriately added to the form, hence eliminating the FormSupport exceptions. I do not know if this is even possible but again IMHO it is a huge limitation to using forms with Ajax. Don't get me wrong, I absolutely love Tapestry5!!! It is an incredible framework but IMHO I fear that limitations such as this will keep it from becoming mainstream.

        If its impossible to fix the framework somehow then I would vote for:

        • option A implemented on the select component. This would update any zone (which is common to how all the other components work).
        • option B implemented as a mix-in (per "Thiago " suggestion)
        Show
        Joe Klecko added a comment - Since no one has responded and this is by far the most voted for jira issue I'll give it a go. IMHO this is a pretty big Ajax handicap for the framework, I will respond by saying that option B is the typical issue, but as you do bring up a good point, there shouldn't be any reason the select component cannot update any zone, which means the issue goes deeper than that and is actually a framework issue. The problem is that the framework does not allow any new form fields to be added via standard zone updates, so the ultimate solution is to fix this (if even possible) and implement option A. If the framework were to somehow know a zone is within a form and that zone is updated (regardless of which component updated the zone), any new fields should be appropriately added to the form, hence eliminating the FormSupport exceptions. I do not know if this is even possible but again IMHO it is a huge limitation to using forms with Ajax. Don't get me wrong, I absolutely love Tapestry5!!! It is an incredible framework but IMHO I fear that limitations such as this will keep it from becoming mainstream. If its impossible to fix the framework somehow then I would vote for: option A implemented on the select component. This would update any zone (which is common to how all the other components work). option B implemented as a mix-in (per "Thiago " suggestion)
        Hide
        Igor Drobiazko added a comment -

        What is actually the use case? Is it A) or B)

        A)
        <t:zone t:id="myZone">
        <t:form>
        <t:select t:id="master" zone="myZone"/>

        <t:if test="bla bla bla">
        <t:delegate to="myBlock"/>
        </t:if>
        </t:form>
        </t:zone>

        <t:block id="myBlock">
        <t:select t:id="slave" />
        </t:block>

        B)
        <t:form>
        <t:select t:id="master" zone="myZone"/>

        <t:zone t:id="myZone"/>
        </t:form>

        <t:block id="myBlock">
        <t:select t:id="slave" />
        </t:block>

        I think B) is more reasonable because in version A) all input is lost when the zone is updated. It doesn't make sense to update the entire form? Does it?

        Show
        Igor Drobiazko added a comment - What is actually the use case? Is it A) or B) A) <t:zone t:id="myZone"> <t:form> <t:select t:id="master" zone="myZone"/> <t:if test="bla bla bla"> <t:delegate to="myBlock"/> </t:if> </t:form> </t:zone> <t:block id="myBlock"> <t:select t:id="slave" /> </t:block> B) <t:form> <t:select t:id="master" zone="myZone"/> <t:zone t:id="myZone"/> </t:form> <t:block id="myBlock"> <t:select t:id="slave" /> </t:block> I think B) is more reasonable because in version A) all input is lost when the zone is updated. It doesn't make sense to update the entire form? Does it?
        Hide
        Thiago H. de Paula Figueiredo added a comment -

        I suggest the AJAX part would be better implemented as a mixin instead, a little like Autocomplete.
        And I agree with Peter about having something like a LinkedSelectPair component. They're would be a good suite for different situations.

        Show
        Thiago H. de Paula Figueiredo added a comment - I suggest the AJAX part would be better implemented as a mixin instead, a little like Autocomplete. And I agree with Peter about having something like a LinkedSelectPair component. They're would be a good suite for different situations.
        Hide
        Peter Stavrinides added a comment -

        IMHO a better approach is without AJAX, perhaps a new component, similar to the radiogroup, all you really need is a way to link the lists and be able to filter on them.

        Show
        Peter Stavrinides added a comment - IMHO a better approach is without AJAX, perhaps a new component, similar to the radiogroup, all you really need is a way to link the lists and be able to filter on them.
        Hide
        Francois Armand added a comment -

        Perhaps the use case should be even more generic than for select only, and be a mixin that take as parameter a zone and an even and does the zone update when the event occurs.

        Moreover, in your use case, I think that there will be some tricky point with the availability of the FormSupport: I'm not sure that today, you can update a zone inside a form if the zone contains fields. Si perhaps there is another bug (or perhaps it's just missing documentation) to enable partial update of a form (I suspect that FormFragment / FormInjector will have a role to play here).

        Show
        Francois Armand added a comment - Perhaps the use case should be even more generic than for select only, and be a mixin that take as parameter a zone and an even and does the zone update when the event occurs. Moreover, in your use case, I think that there will be some tricky point with the availability of the FormSupport: I'm not sure that today, you can update a zone inside a form if the zone contains fields. Si perhaps there is another bug (or perhaps it's just missing documentation) to enable partial update of a form (I suspect that FormFragment / FormInjector will have a role to play here).

          People

          • Assignee:
            Igor Drobiazko
            Reporter:
            Geoff Callender
          • Votes:
            51 Vote for this issue
            Watchers:
            31 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development