[seam-dev] Module reviews

[Gavin King]

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