Spring Web Flow 2.2.1 is out, Spring Web Flow 2.3.0 next

[Rossen Stoyanchev]

That issue will also result in changes to SpringValidatorAdapter. That aside how do you imagine specifying validation groups for a given view state?

[Paul Wilson]

Correct me if I'm wrong, but SpringValidatorAdapter already has:

public <T> Set<ConstraintViolation<T>> validate(T object, Class<?>... groups) {
		return this.targetValidator.validate(object, groups);
	}

I'm writing a framework off of Webflow that allows validation groups to be specified using the fully qualified class name separated by commas. I split it and use the class loader to find groups by their name. I then collate them and pass them to the groups parameter [1]. I know that Seam remoting allows you to specify only the unqualified name which is much cleaner [2], but I don't know how it determines the correct type to use in this case.

I imagine a neater way would be to define them within the view as a separate element similar to the way the 'binding' element operates?

Regards,
Paul

[1] This is a bit tricky because 'groups' is an array of a generics but it is possible.
[2] http://docs.jboss.org/seam/3/remotin...on.html#d0e742

[Rossen Stoyanchev]

Yes SpringValidatorAdapter does implement all javax.validation.Validator methods. However, the one invoked from ValidatorHelper is:

public void validate(Object target, Errors errors) { }

The above method adapts Bean Validation errors and registers them with the Spring MVC Errors instance passed in. This way errors raised via JSR-303 validation can be treated as any other validation errors in Spring MVC with regards to being displayed through the form:errors tag or customized through the default MessageCodesResolver.

Following the conventions approach used presently to discover validation methods and validator objects, we could try to come up with some suitable convention. Alternatively a view state attribute named "validationGroups" could be expected. The value would either be fully qualified class names or unqualified with the package of the model assumed by default. I suppose the common case would be one validation group per view state so even fully qualified wouldn't be too bad.

If you don't mind please raise a ticket in JIRA as that would be a better place to capture this conversation.

[Paul Wilson]

Done: https://jira.springsource.org/browse/SWF-1453