Adam Winer wrote:
Definitely a very interesting approach; one problem is that it'll validate too much. For example, it'll validate beans that aren't even used on the current page. It'll also validate beans that aren't yet valid because they're being created and populated over multiple pages, and beans that weren't set on this request because they're in a different form (or subform) than the one that was submitted.
Yes, these are real problems. One of the things I was toying with extending hibernate validator (or wrapping spring-validator or commons-validator to use an annotation based approach) and adding a context property that indicates which properties should validated when.
Hibernate validator will also set database schema constraints, I want to keep that. But that feature is enabled by a marker interface on the validator, so if the wrapper approach supports that marker interface it may work out ok.
But the validator I posted was just an experiment. There are lots of issues still to work out. Especially how to get a single validation specification that is used at the db-level, app-level, and jsf-level, and javascript-level (when appropriate of course).
The interesting question is how to tie an annotation driven approach like this - which I really like - to all of the information resident in the UIComponent tree.
Yes. Any ideas? -bk
