tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard Lewis Ship" <hls...@gmail.com>
Subject Re: T5: parameter value vs parameter binding
Date Sat, 20 Jan 2007 14:13:32 GMT
On 1/15/07, Kent Tong <kent@cpttm.org.mo> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message