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