Tapestry 5
  1. Tapestry 5
  2. TAP5-1663

The @BindParameter annotation should support inherited parameters


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


      Currently the @BindParameter annotation (that binds a parameter of a mixin to a parameter in the component the mixin is applied to),
      can be applied only to formal parameters of the containing component and not to parameters that are inherited by the containing component by embedded components.
      I think it is natural that inherited parameters are included in the search for parameters to bind to with the @BindParameter annotation.
      Here is a motivating example:

      public class MyComponent

      { @Component(parameters = "blankOption=inherit:blankOption", publishParameters="blankOption") private Select select; }

      public class MyMixin

      { @BindParameter private BlankOption blankOption; }

      And we get:

      Containing component MyComponent does not contain a formal parameter matching any of (blank), blankOption.

      1. TAP5-1663.patch
        11 kB
        Dragan Sahpaski


        Dragan Sahpaski created issue -
        Dragan Sahpaski made changes -
        Field Original Value New Value
        Attachment TAP5-1663.patch [ 12500450 ]
        Dragan Sahpaski made changes -
        Comment [ This patch is rather small (entire patch file is 253 lines long), and contains integration tests.

        Patch Summary:
        Files changed 4:
         1. BindParameterWorker: Here is the main logic for inspecting published parameters. Also the Exception text is changed to contain info that formal and published parameters are searched.
         2. BindParameterDemo.java
         3. BindParameterDemo.tml - Added publish1 component with EchoValueWithId mixin.
         4. CoreBehaviorsTests.java
           - public void bindparameter() - added few assertions for detecting if the published value is there. It is the same concept as the EchoValue mixins
           - public void bindparameter_nomatchingparameter() - changed asserted value of the exception text.

        Files added 1:
         1. EchoValueWithId mixin in integration/app1: Same as EchoValue mixin except it does take id as a parameter and doesn't use the container's clientId. This is needed because it is applied to a Publish1 component that is not a clientElement.

        Public API changes: none
        Internal API changes: none

        Performance issues:
         - BindParameterWorker has a recursive search (iterative implementation) for published parameters in embeddedComponents. I think this is better than changing public and internal interfaces to contain metadata for published parameters etc.
        A alternative implementation would be to put this metadata in ComponentModel, something like isPublishedParameter or getPublishedParameters. I think this is not necessary especially because no one has issued a need for it. ]
        Robert Zeigler made changes -
        Assignee Robert Zeigler [ ongakugainochi ]
        Component/s tapestry-core [ 12312470 ]
        Robert Zeigler made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Fix Version/s 5.3 [ 12316024 ]
        Resolution Fixed [ 1 ]


          • Assignee:
            Robert Zeigler
            Dragan Sahpaski
          • Votes:
            2 Vote for this issue
            2 Start watching this issue


            • Created: