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
