Tapestry
  1. Tapestry
  2. TAPESTRY-394

Default for listener parameter of DirectLink, etc.

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 4.0
    • Fix Version/s: 4.1.3
    • Component/s: Framework
    • Labels:
      None

      Description

      The following is a common convention in Tapestry:

      <p>
      <a href="#" jwcid="clear@DirectLink" listener="listener:doClear">clear counter</a>
      </p>

      Looking at this, it seems to me that the default for listener could be calculated; that is, capitalize the component id to "Clear" and prefix with "do".

      I.e.

      getContainer().getListeners().getListener("do" + capitalize(getId()));

      Of course, for auto-generated ids, this would be a failure (either no listener found, or something more explicit).

        Activity

        Hide
        Cyrille added a comment -

        For exemple the t:loop component can generate t:actionLink url like I would like : the action is not the uniqueId of the component :

        <t:loop source="1..3" value="guess">
        <t:actionlink t:id="showStuff" t:context="guess">$

        {guess}

        </t:actionlink>
        </t:loop>

        .../do.showStuff/1
        .../do.showStuff/2
        .../do.showStuff/3

        with a t:listener I could do the same without the t:loop component.

        Show
        Cyrille added a comment - For exemple the t:loop component can generate t:actionLink url like I would like : the action is not the uniqueId of the component : <t:loop source="1..3" value="guess"> <t:actionlink t:id="showStuff" t:context="guess">$ {guess} </t:actionlink> </t:loop> .../do.showStuff/1 .../do.showStuff/2 .../do.showStuff/3 with a t:listener I could do the same without the t:loop component.
        Hide
        Ben Dotte added a comment -

        I've got this implemented locally for components that have a required listener (XTile, DirectLink, InvokeListener, Suggest) but it isn't clear to me how or whether this should be used for components with non-required listeners. How would you tell if the user doesn't want a listener vs. assuming an implicit one? I suppose we could look for a listener and fail silently if we don't find one (for components with non-required listeners) but that seems less than ideal.

        Show
        Ben Dotte added a comment - I've got this implemented locally for components that have a required listener (XTile, DirectLink, InvokeListener, Suggest) but it isn't clear to me how or whether this should be used for components with non-required listeners. How would you tell if the user doesn't want a listener vs. assuming an implicit one? I suppose we could look for a listener and fail silently if we don't find one (for components with non-required listeners) but that seems less than ideal.
        Hide
        Ben Dotte added a comment -

        This is complete for the XTile, DirectLink, InvokeListener, and Suggest components. In each case, the listener parameter has been made optional, and if it is not used, Tapestry will attempt to find a listener whose name is composed of the capitalized component id, prefixed by "do". Added unit tests and updated the site documentation.

        Show
        Ben Dotte added a comment - This is complete for the XTile, DirectLink, InvokeListener, and Suggest components. In each case, the listener parameter has been made optional, and if it is not used, Tapestry will attempt to find a listener whose name is composed of the capitalized component id, prefixed by "do". Added unit tests and updated the site documentation.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development