Mailing-List: contact commits-help@tapestry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tapestry.apache.org
Date: Mon, 24 Oct 2011 14:27:32 +0000 (UTC)
From: "Dragan Sahpaski (Updated) (JIRA)" <jira@apache.org>
To: commits@tapestry.apache.org
Message-ID: 
 <880218362.8657.1319466452707.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1290632007.6452.1316783847124.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (TAP5-1663) The @BindParameter annotation should
 support inherited parameters
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/TAP5-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dragan Sahpaski updated TAP5-1663:
----------------------------------

    Attachment: TAP5-1663.patch

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.
                
> The @BindParameter annotation should support inherited parameters
> -----------------------------------------------------------------
>
>                 Key: TAP5-1663
>                 URL: https://issues.apache.org/jira/browse/TAP5-1663
>             Project: Tapestry 5
>          Issue Type: Improvement
>            Reporter: Dragan Sahpaski
>            Priority: Minor
>              Labels: mixin
>         Attachments: TAP5-1663.patch
>
>
> Hi,
> 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:
> org.apache.tapestry5.ioc.util.UnknownValueException
> Containing component MyComponent does not contain a formal parameter matching any of (blank), blankOption.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira