[seam-dev] Module reviews

[Gavin King]

P.S. shouldn't FormValidator be called ActionForm?

*ducks*

On Tue, Jun 15, 2010 at 2:17 AM, Gavin King <gavin.king at gmail.com> wrote:
> On Mon, Jun 14, 2010 at 5:23 PM, Lincoln Baxter, III
> <lincolnbaxter at gmail.com> 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 at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org