> I don't see how or why it assumes that. Why could I not have
multiple<br>
> validators which all specified that they belonged to the same form?<br><br>I think I was having a bit of a dyslexic day all around...<br><br><div class="gmail_quote">On Mon, Jun 14, 2010 at 11:57 PM, Lincoln Baxter, III <span dir="ltr"><<a href="mailto:lincolnbaxter@gmail.com">lincolnbaxter@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hehe :)<br><br>I'm in favor of the @FormValidator(...) annotation. Sold, for an annotation.<br>
<font color="#888888"><br>--Lincoln</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Mon, Jun 14, 2010 at 8:19 PM, Gavin King <span dir="ltr"><<a href="mailto:gavin.king@gmail.com" target="_blank">gavin.king@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">P.S. shouldn't FormValidator be called ActionForm?<br>
<br>
*ducks*<br>
<div><div></div><div><br>
On Tue, Jun 15, 2010 at 2:17 AM, Gavin King <<a href="mailto:gavin.king@gmail.com" target="_blank">gavin.king@gmail.com</a>> wrote:<br>
> On Mon, Jun 14, 2010 at 5:23 PM, Lincoln Baxter, III<br>
> <<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>> wrote:<br>
><br>
>> Unfortunately, this assumes the existance of only 1 FormValidator per form,<br>
>> which is likely not the case in many scenarios;<br>
><br>
> I don't see how or why it assumes that. Why could I not have multiple<br>
> validators which all specified that they belonged to the same form?<br>
><br>
> Or are you trying to say that it encourages one form per form<br>
> validator? (That's not what you wrote.)<br>
><br>
>> It encourages breaking<br>
>> separation of concerns (where now you have only 1 validator handling<br>
>> multiple scenarios per form -- if you do have multiple scenarios-- and many<br>
>> different combinations of fields that may or may not be related.<br>
><br>
> So the intention here is that you would create reusable form<br>
> validators that would attach to common, repeated combinations of input<br>
> fields that appear in many forms? This seems deeply, deeply doubtful<br>
> to me. It seems that in this case you should be composing a reusable<br>
> JSF component out of the smaller fields and attaching a single<br>
> validator to it. Cross-field validation is usually something that is<br>
> very specific to a single form in the application, in my experience.<br>
><br>
>> This also<br>
>> breaks re-use of FormValidators by hard-binding form field IDs to validator<br>
>> field names.<br>
><br>
> Again, I don't see that cross-field validation is something that is<br>
> often reusable. On the contrary, it's highly uncommon to see repeated<br>
> combinations of fields in several different forms, and when you do see<br>
> it, it's usually a case where you should factor out some higher-level<br>
> control (like a datetime control or whatever).<br>
><br>
> I'm not saying that it's unimaginable, just that it's not at all the<br>
> common case.<br>
><br>
>> There is also the danger of bleeding across views, where a formValidator is<br>
>> created that "accidentally" becomes attached to another form with the same<br>
>> name on a different page, or when you want to use the same form-name, but<br>
>> can't because you will automatically trigger form validation (that would<br>
>> likely fail (forcing you to disable it in some way, or choose a different<br>
>> name.)<br>
><br>
> That all sounds totally trivial to solve via a combination of view id<br>
> and form id.<br>
><br>
> @FormValidator(view="login.jsf", form="loginForm")<br>
><br>
>> This could also have the undesired effect of attaching validators that are<br>
>> not intended to be form validators (perhaps validators that were not even<br>
>> defined by the developer themselves -- e.g.: included in a JAR file.)<br>
><br>
> huh?<br>
><br>
>> Does this feature really buy us much?<br>
><br>
> Well, it lets you encapsulate all the information about the form<br>
> validator in exactly one place, saving you the need to add a special<br>
> tag to your JSF page. And keeping all information about validation<br>
> outside of the view definition (which is the case with single-field<br>
> validation via bean validation annotations). Now, I would not argue<br>
> that this is something super-important from a software engineering<br>
> perspective, but it certainly looks clean and is convenient in the<br>
> common case. When I looked at the <formValidator/> tag in the JSF<br>
> view, it looked anything but clean. I'm talking pure aesthetics here.<br>
><br>
><br>
> --<br>
> Gavin King<br>
> <a href="mailto:gavin.king@gmail.com" target="_blank">gavin.king@gmail.com</a><br>
> <a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br>
> <a href="http://hibernate.org" target="_blank">http://hibernate.org</a><br>
> <a href="http://seamframework.org" target="_blank">http://seamframework.org</a><br>
><br>
<br>
<br>
<br>
--<br>
Gavin King<br>
<a href="mailto:gavin.king@gmail.com" target="_blank">gavin.king@gmail.com</a><br>
<a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br>
<a href="http://hibernate.org" target="_blank">http://hibernate.org</a><br>
<a href="http://seamframework.org" target="_blank">http://seamframework.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><div><div></div><div class="h5">-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br><a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
"Keep it Simple"<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com">http://ocpsoft.com</a><br><a href="http://scrumshark.com">http://scrumshark.com</a><br>"Keep it Simple"<br>