Hi,

In T5, how would like to configure a component? For example, let's imagine
a component type ColorText that outputs a string in a certain color. You're
now using this component in a page.

First, an all-binding style (same concept as in T4):

@ComponentClass
public class MyPage
{
    @Component(parameters={"color=color", "text=literal:I am in red"})
    private ColorText _colorText;

    public Color getColor()
    {
        return Color.RED;
    }
}

Alternatively, a type-safe setter style:

@ComponentClass
public class MyPage
{
    @Component
    private ColorText _colorText;

    //This method will be called just before the component _colorText
    //is rendered.
    public void configureColorText()
    {
        _colorText.setColor(Color.RED);
        _colorText.setText("I am in red");

    }
}

This ColorText will not update any value on form submission so all we
need is to provide values to its parameters. If it was a TextField, 
then the two approaches will be like:

The all-binding style:

@ComponentClass
public class MyPage
{
    @Component(parameters={"value=name", "validator=required,minLength=10"})
    private TextField _textField;
    private String _name;

}

The type-safe setter style:

@ComponentClass
public class MyPage
{
    @Component
    private TextField _textField;
    private String _name;

    public void configureTextField()
    {
        _textField.setValueBinding("name"); //read and write
        _textField.setValidator(new Required(), new MinLength(10));
        ...
    }
}


So far, I've collected the following PROs and CONs for each approach.

The all-binding style:
1) Less typing.
2) Automatic data type conversion. For example, if a parameter is expecting
an Iterable, you can pass it a binding expression that returns an array.
Tapestry will automatically convert it to an Iterable.
3) Consistency across all parameters. They will use bindings no matter they
only read the value or perform read and write.

The type-safe setter style:
1) IDE auto-completion. The IDE will help you input the setters and the
parameter values.
2) Compile time parameter name checking. If you get the name of parameter 
wrong, the call to the setter simply won't compile.
3) Compile time parameter value type checking. If you pass say a String to
setColor(), it simpy won't compile.
4) Refactoring. If you rename a parameter, the calls to the setter will
be changed automatically.
5) The Javadoc of the component class is the component doc. No need to devise
a new mechanism to write component doc.
6) Easier user level innovation. For example, if one would like to write
a new Validator, it's easier because it's just a Java class. With the all-
binding style, one will have to come up with a initializer syntax, register
it using a configuration under a validator name, while it's still limited 
to having a single argument.

The above is just my observations. What's your take? Which one would you
use if both are available in T5?

--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to