You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Jesse Kuhnert <jk...@gmail.com> on 2007/05/28 00:42:22 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/ t

Hmmm ....I'm very tempted to think about doing this for more property types
....Like any property called "listener/action/field/displayName/etc..."
.Hmm...

On 5/27/07, jkuhnert@apache.org <jk...@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.
>
> 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.
>
>


-- 
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com