Howard Lewis Ship <hlship <at> gmail.com> writes:
> 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),
The component should provide itself (or its ComponentResources) as
an argument to the check() method of FieldValidator. As this info
is supplied at the time of the call, we don't need to provide it
at construction time:
_textField.setValidator(new Required(), new MinLength(10));
This may allow us to pool and share validators (eg, "Required" as it
isn't bound to any particular component). Again, this is static structure,
dynamic behavior.
> and eventually, how it will provide an
> automatic default for the validators based on annotations on the
> setter method.
The component can determine default validators before rendering, also
based on the setter method. This logic can be extracted to a single
class, maybe even a mixin.
> 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.
I think with a bit of annotation and byte code generation, this can be
done for the type safe setter approach:
class TextField {
@Binding
private Object value;
private Validator validator;
}
> You don't have to
> worry about field converstions. You don't have to provide getter and
> setter methods (except for testing).
True. Those are trade-offs for compile time checking.
> Unless you provide a TypeCoercer from String to Color.
Again, trade off for compile time checking.
> > 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.
For the code inside the same project, refactoring will work just fine.
For other code, there will be compile errors, which is a good thing
as it is tell us something is wrong.
The case about parameter alias is not really the same thing. I may
just rename a parameter during development because I found a better
name. I don't want to keep the old name around. If we really want
to achieve the same effect as parameter alias, we can just provide
a new setter and mark the old setter as deprecated, using the standard
Java mechanism. The warnings will be seen at compile time. It is also
easier for Java developers to understand.
> Javadoc with privates included can cover this. Perhaps some form of
> JavaDoc extension that omits privates, but includes <at> Parameter fields.
Exactly what I was talking about. We need to devise new mechanisms to
do what the existing mechanisms in Java are doing fine.
> <at> Component (parameters="validate=prop:myFieldSpecialValidator")
> private TextField _myField;
>
> public FieldValidator getMyFieldSpecialValidator()
> { return new FieldValidator() { ... } ; }
True, but this will not work when we need multiple validators. Yes,
I know about the $bean notation. This is another example of devising
new mechanisms for work that can already be done. All we need is to
provide a list of objects (validators) that has access to the field.
--
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]
