Hehe :) I'm in favor of the @FormValidator(...) annotation. Sold, for an annotation.
--Lincoln On Mon, Jun 14, 2010 at 8:19 PM, Gavin King <[email protected]> wrote: > P.S. shouldn't FormValidator be called ActionForm? > > *ducks* > > On Tue, Jun 15, 2010 at 2:17 AM, Gavin King <[email protected]> wrote: > > 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 > > > > > > -- > Gavin King > [email protected] > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"
_______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
