[seam-dev] Module reviews

[Lincoln Baxter, III]

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 <gavin.king at gmail.com> wrote:

> 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
>



-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100614/418ad11f/attachment.html