On 1/27/07, Kent Tong <[EMAIL PROTECTED]> wrote:
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));
...
}
}
Thing is, that would have to be
_textField.setValidator("required,minlength=10").
The way the validate binding factory works, it needs to know a lot
about the component being bound as well as the container component.
That's how it obtains the field's label (for presenting error
messages), how it access's the containers catalog (to looks for
approprately keyed messages), and eventually, how it will provide an
automatic default for the validators based on annotations on the
setter method.
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.
4) Less code when writing components. You just provide the field and
access it freely.
You don't have to worry about what's a simple property and what's a
bi-directional parameter, they look the same to you. You don't have to
worry about field converstions. You don't have to provide getter and
setter methods (except for testing).
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.
Unless you provide a TypeCoercer from String to Color.
4) Refactoring. If you rename a parameter, the calls to the setter will
be changed automatically.
Though this will break existing code, whereas implementing T4's
parameter aliases would allow existing code to work after an upgrade,
with warnings.
5) The Javadoc of the component class is the component doc. No need to devise
a new mechanism to write component doc.
Javadoc with privates included can cover this. Perhaps some form of
JavaDoc extension that omits privates, but includes @Parameter fields.
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.
Or:
@Component (parameters="validate=prop:myFieldSpecialValidator")
private TextField _myField;
public FieldValidator getMyFieldSpecialValidator()
{ return new FieldValidator() { ... } ; }
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]
--
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]
