On Thu, Oct 15, 2009 at 9:43 PM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote:
> Em Thu, 15 Oct 2009 16:06:05 -0300, Igor Drobiazko < > igor.drobia...@gmail.com> escreveu: > > Ok, I thought about it a little bit. Would like to hear some objections >> before I start coding. The main challenge is the difference between >> validation mechanism in Tapestry and in jsr 303. In Tapestry a validator >> is only aware of the value being validated. >> > > Tapestry is aware of the property being validated too > (ValidationConstraintsGenerator). That's exactly how the @Validate > annotation works. So my suggestion is to add ValidationConstraintsGenerators > for each single-property annotation (@NotNull, @Email, @Size, @Length, etc), > something that can be done with the existing Tapestry infrastructure. I have > this already implemented for Hibernate Validator 3 (for annotations that > have some validation that already exists in Tapestry) and I'll donate the > code. Very little will need to be changed (just package names, I guess). > Then we'll need to add support for object validation. We keep the value > validation that we have now and then add the object validation support. > Better validate something twice than never. :) > 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. 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. http://anonsvn.jboss.org/repos/hibernate/beanvalidation/api/trunk/src/main/java/javax/validation/ConstraintValidator.java Why shall we bloat Tapestry code unnecessary? Just image you want to add your own annotation @MyFavoriteAnnotation. Why should you ever write Tapestry code for it? You add the annotation, annotate your classes and that's it. No more work should be necessary. The new should not be upgraded every time jsr 303 guys add a new annotation. The same is when you add your own annotations. > > tapestry-crud-hibernate-validator can be found at > http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/tapestry-crud-hibernate-validator/trunk/(browse) > and > https://ars-machina.svn.sourceforge.net/svnroot/ars-machina/tapestry-crud-hibernate-validator/trunk/(checkout). > > This fact makes the integration tricky if you care about the backward >> compatibility of the Tapestry API. >> > > Not that hard. :) > > - I would like to add new maven module called 'tapestry-jsr303' or >> 'tapestry-bean-validation' (what is actually the better name?) >> > > tapestry-bean-validation, so we shouldn't remember what each JSR number > means. :) This is fine. > > > - since tapestry validators are only aware of the value being validated, >> we need a new parameter for the Form component. Let's call it 'object' (or >> 'validate'). Once you want to use jsr303 validator you should pass the >> object to validate into this parameter. It can be a JavaBean or even a >> page/component. >> > > I suggest it to be 'validate' (object is too generic in this case) and to > receive a List of objects, as a single form can edit more than one object > (specially when using Grid and AjaxFormLoop). > > - the Form's 'object' parameter defaults to Form's container. >> > > Ok! > > - the Form component stores the value of the 'object' parameter in >> environment service, let's say BeanVlidationContext, and pushes this >> service into the environment. >> > > Why? 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. > > > - the new module overrides the default implementation of the >> FieldValidatorDefaultSource by an implementation which uses jsr 303 >> validator. This implementation peeks the BeanVlidationContext from >> environment to obtain the bean to validate. Maybe a pipeline is a better >> alternative than overriding the service in order to mix both validator >> mechanism (tapestry and jsr303)? >> > > I would propose an ObjectValidator interface added to Tapestry-IoC (non-web > applications would be able to use it too) as ordered pipelined service. > > I haven't seen the need for pushing the object being validated in the > environment. It is useful when one component needs to pass some value to > their inner components, and I don't see the need for this to do validation. > Why doesn't the form invoke the object validation pipeline itself? Because now validation takes place inside the fields. The method 'processSubmission' does the job. > > > - BeanEditForm passes the value of its 'object' parameter into Form's >> parameter 'object'. >> > > Ok! > > - the jsr 303 doesn't cover client validation, so this part can be done by >> Tapestry. >> > > This can be done by adding ValidationConstraintsGenerators for each > single-property annotation (@NotNull, @Email, @Size, @Length). Using my > tapestry-crud-hibernate-validator package, I hardly need to use t:validate > anymore, and I get all the client-side validation done. :) Again, why shall we add some much classes? > > > -- > 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
