My opinions on this must be obvious from wanting the binding logic to
be smarter / do even more. I don't like writing redundant code when I
know the framework could do it for me.
On 1/20/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
On 1/15/07, Kent Tong <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I believe that a major reason for having parameter bindings for components
> instead of simply parameter values is that bindings are bi-directional.
> However, this capability is basically only used by form components. Even for
> those components, only a minority of parameters (usually the "value") are
> truly bi-directional. Therefore, why not provide parameter values to
> components and reserve the use of binding to those limited cases? For
> example, given a component with t:id="productName" in the template, before
> rendering that component, Tapestry will call setupProductName() on the page
> object so that the page object can provide the parameter values:
>
> class ProductPage {
> int productId;
> String productName;
>
> void setupProductName(TextField productName) {
> productName.setValueBinding("prop:productName"); //The concept of
> binding remains here
> productName.setDisplayName("product name");
> productName.setValidator(new RegExValidator("..."));
> }
> }
>
> While the parameter values are provided in the method body, Tapestry can
> also determine the component type using the type of the parameter (TextField
> here).
>
> Using Java expressions to setup components has the following benefits:
> 1) This is a concept the programmer is very familiar with. Therefore it's
> easy to learn and to use.
> 2) IDE support (eg, renaming RegExValidator to automatically update the
> code).
> 3) Compile time checking. It's impossible to enter an incorrect parameter
> name. The value is also type checked.
>
> What do you think? Is this workable?
Anything is workable. Is this Tapestry? It doesn't feel like it,
more like a step closer to Wicket.
I can see the appeal of this in one way, it looks a lo more like Swing.
There are some advantages that you mentioned in terms of refactoring.
But it's so asymmetric ...
There's more code to write. If a property ever changes from
set-and-forget to read/write or even read-on-demand, it may affect
existing code.
Many convieniences and automatic conversions are lost.
I have thought of adding a lifecycle method that would allow you to
bind component parameters in Java code, rather than in annotations or
in the template.
So, I'm still unconvinced about such a significant change. I really
think that Tapestry 4 pretty much nailed component parameters, and T5
mostly changes that model by attaching them to fields instead of
abstract properties.
>
>
> --
> View this message in context:
http://www.nabble.com/T5%3A-parameter-value-vs-parameter-binding-tf3015059.html#a8372805
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
