You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by andyhot <an...@di.uoa.gr> on 2007/06/01 04:37:39 UTC

Re: svn commit: r542045 - in /tapestry/tapestry4/trunk: tapestry-examples/TimeTracker/src/context/ tapestry-framework/src/descriptor/META-INF/ tapestry-framework/src/java/org/apache/tapestry/ tapestry-framework/src/java/org/apache/tapestry/binding/ tapestr...

jkuhnert@apache.org wrote:
> Author: jkuhnert
> Date: Sun May 27 15:34:36 2007
> New Revision: 542045
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=542045
> Log:
> Fixes TAPESTRY-1513.  Added a new configuration type for BindingSource which controls which binding factory to use based on the name of the property the binding is going to be bound to - if known.  The logic only kicks in when no binding prefix has been specified.
>   

Well, i'm not sure about this... i mean i like the idea - what i dont 
like is the fact that inside a template
updateComponents="comp1" and updateComponents="literal:comp1" can 
potentially behave differently

In my case, it was probably because i was defining my own 
updateComponents parameter as String
instead of a List


> The point in adding it was so that people can use statements like updateComponents="compA, compB" and have the system automatically resolve the unique clientId for each component specified depending on the context in which the binding is invoked.  Sort of like the clientid: binding only this one kicks in automatically and may be easier for people to understand than throwing another binding type at them.
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org