On Mon, Jun 14, 2010 at 5:23 PM, Lincoln Baxter, III <[email protected]> wrote:
> Unfortunately, this assumes the existance of only 1 FormValidator per form, > 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. > This also > breaks re-use of FormValidators by hard-binding form field IDs to validator > field names. 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 common case. > There is also the danger of bleeding across views, where a formValidator is > 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 > name.) That all sounds totally trivial to solve via a combination of view id and form id. @FormValidator(view="login.jsf", form="loginForm") > This could also have the undesired effect of attaching validators that are > not intended to be form validators (perhaps validators that were not even > defined by the developer themselves -- e.g.: included in a JAR file.) huh? > 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. -- Gavin King [email protected] http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
