A further argument not to do the validation inside the form component
is the decoration of fields. In case of errors more code is needed to
highlight the fields in error.
I invite the others to participate in this discussion.
16.10.2009, в 00:48, Igor Drobiazko <igor.drobia...@gmail.com>
написал(а):
Thiago, the jsr 303 is much more than annotations: there are
validation groups, there is xml based validation definition. Why
shall we cut all these features? How do you want to generate
constraints which are provided inside xml? There is no way to get
them from ValidationConstraintGenerator. I know there is no xml
inside Tapestry but we should not limit the possibilities of the
JSR. The jsr validation should work same, independent form the
source the constraints are defined in (annotations or xml). That's
why I would prefer the approach I suggested.
IMO, the integration should be very simple. No extra code, no
limitations of the jsr. It should just work.
It looks like it is the matter of taste. What do the others think
about it?
On Thu, Oct 15, 2009 at 10:55 PM, Thiago H. de Paula Figueiredo <thiag...@gmail.com
> wrote:
Em Thu, 15 Oct 2009 17:18:38 -0300, Igor Drobiazko <igor.drobia...@gmail.com
> escreveu:
Well, I don't think it is a good idea to create adapters for every
single
annotation from jsr 303. Every time they add a new annotation, we
have to
adjust our code.
I guess you didn't get my suggestion yet. My idea is to add both
ValidationConstraintGenerator validation (so client-side validation
is added automatically) and object-wide validation. Both together.
This way, validation using Tapestry or not using Tapestry will yield
the exact same result.
Just emphisizing a little more: we need
ValidationConstraintGenerator for client-side validation to be added
automatically.
One of the key feature of the jsr 303 is the easy to add
new validators. You create a new annotation which is validated by a
ConstraintValidator.
IMHO, this is not a problem at all. *We don't need to add a
ValidationConstraintGenerator for each possible validation
annotation*. All I'm suggesting to add
ValidationConstraintGenerators for every matching Tapestry
validator. We'll validate objects themselves, so every annotation is
validated, having a ValidationConstraintGenerator for it or not. And
we'll also need to validate the object itself using JSR 303, so
we're not losing any validation by not having a
ValidationConstraintGenerator for each annotation.
The reason is that the jsr 303 code should work without to write
Tapestry
code. How should FieldValidatorDefaultSource or
ValidationConstraintGenerator know the bean being validated? You
need to
pass the bean from Form component to the place where jsr 303
validation
takes place.
Same reasoning as above: ValidationConstraintGenerators in addition
to object-level validation, not replacing them.
Because now validation takes place inside the fields. The method
'processSubmission' does the job.
We want to add validation that can't be done field-by-field, so,
IMHO, propagating object validation to field components will not help.
Summary: I want to have what Tapestry does now (field-based
validation) used *together* with the new object-based validation
we'll add.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
--
Best regards,
Igor Drobiazko
