Martin Strand wrote:
No, leaving the decision up to the developer is not a solution at all.
Tapestry should have one proper way to do things and if someone is not
satisfied with it they can use a 3rd party lib that provides the
functionality they need. This will also reduce confusion for newcomers.
I'd prefer o leave parameters as they are (ie
parameters={"color=color"}) but the most important thing is that there's
one "proper" way to do things.
I thought to keep out of this discussion, but I couldn't help it:
Yes, where its possible: one way to do things. taking the xml out is a
bless, now one can define components in "only" two ways instead of 3...
but I would vote for the (until now unpopular) binding:
@Bindings([EMAIL PROTECTED](name="...",value="...")})
but I guess noone (except me) likes that extra typing... :(
Cheers,
Ron
On Sat, 27 Jan 2007 18:01:41 +0100, Hugo Palma <[EMAIL PROTECTED]>
wrote:
I think both are valid options. In my opinion both ways should be
provided by the framework and it should be a developers decision to use
the one that fits his needs/taste.
Question: what would happen if the developer configured the same
component both ways in the same page (by mistake or something) ? I think
that this shouldn't be allowed and a runtime exception should be thrown.
This would prevent some "distraction" programming errors.
Kent Tong 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));
...
}
}
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
