Re: [seam-dev] Module reviews

P.S. shouldn't FormValidator be called ActionForm? *ducks* On Tue, Jun 15, 2010 at 2:17 AM, Gavin King <gavin.king(a)gmail.com&gt; wrote: > On Mon, Jun 14, 2010 at 5:23 PM, Lincoln Baxter, III > <lincolnbaxter(a)gmail.com&gt; 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 > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org