On Mon, Jun 14, 2010 at 5:23 PM, Lincoln Baxter, III
Unfortunately, this assumes the existance of only 1 FormValidator per
which is likely not the case in many scenarios;
I don't see how or why it assumes that. Why could I not have multiple
validators which all specified that they belonged to the same form?
Or are you trying to say that it encourages one form per form
validator? (That's not what you wrote.)
It encourages breaking
separation of concerns (where now you have only 1 validator handling
multiple scenarios per form -- if you do have multiple scenarios-- and many
different combinations of fields that may or may not be related.
So the intention here is that you would create reusable form
validators that would attach to common, repeated combinations of input
fields that appear in many forms? This seems deeply, deeply doubtful
to me. It seems that in this case you should be composing a reusable
JSF component out of the smaller fields and attaching a single
validator to it. Cross-field validation is usually something that is
very specific to a single form in the application, in my experience.
breaks re-use of FormValidators by hard-binding form field IDs to validator
Again, I don't see that cross-field validation is something that is
often reusable. On the contrary, it's highly uncommon to see repeated
combinations of fields in several different forms, and when you do see
it, it's usually a case where you should factor out some higher-level
control (like a datetime control or whatever).
I'm not saying that it's unimaginable, just that it's not at all the
There is also the danger of bleeding across views, where a
created that "accidentally" becomes attached to another form with the same
name on a different page, or when you want to use the same form-name, but
can't because you will automatically trigger form validation (that would
likely fail (forcing you to disable it in some way, or choose a different
That all sounds totally trivial to solve via a combination of view id
and form id.
This could also have the undesired effect of attaching validators
not intended to be form validators (perhaps validators that were not even
defined by the developer themselves -- e.g.: included in a JAR file.)
Does this feature really buy us much?
Well, it lets you encapsulate all the information about the form
validator in exactly one place, saving you the need to add a special
tag to your JSF page. And keeping all information about validation
outside of the view definition (which is the case with single-field
validation via bean validation annotations). Now, I would not argue
that this is something super-important from a software engineering
perspective, but it certainly looks clean and is convenient in the
common case. When I looked at the <formValidator/> tag in the JSF
view, it looked anything but clean. I'm talking pure aesthetics here.