Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Message-ID: <39656D2C.43E97076@eng.sun.com>
Date: Thu, 06 Jul 2000 22:39:56 -0700
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
MIME-Version: 1.0
To: tomcat-user@jakarta.apache.org
Subject: Re: Exceptional Question
References: <001201bfe7c1$6969a9a0$39117118@rct1.bc.wave.home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Rob S." wrote:

> > In the Struts framework (http://jakarta.apache.org/struts), I approached
> > this
> > issue by having a validate() method in my form bean return a String
> > array of
> > messages for all of the errors that have been detected, rather than
> > throwing
> > exceptions on individual fields.  That way, I can display all the errors
> > at
> > once.
>
> Ahhh k, those messages being keys to the MessageResource and set to the
> localized message, displayed using <struts:error/>.  I gave a preliminary
> read through the MVC intro doc, which was a rock and roll adventure.  I've
> only heard of it before, so it was sort of thick.  I'm sure the more
> experienced web people will probably get it a lot more quickly tho'.  What I
> *do* like is the use of an errors collection & keys, which makes things
> like:
>
> <%= errors.get(Bean.ATTR_ERROR) %>
>
> much cleaner than having to deal with individualized exceptions and more
> flexible than only being able to display the latest error.  Less powerful &
> efficient overall, but perhaps more appropriate for small-time sites (mine
> included).
>
> One thing I'm tempted to do is figure out elegant ways to only use
> get/setProperty to get all of my bean work done.  Doesn't usually turn out
> that way tho' =)  I wonder if the next JSP spec will provide more powerful
> bean tags.
>

There are two classes of "exceptional questions" that I've found do not really
fit the "check it in the bean setters" approach:

* Context-specific errors where there is more than one field
  involved (such as "field A is required if you selected checkbox B,
  but it must be blank otherwise").

* Errors that involve checking external resources ("is this really a
  valid customer identifier?").

In almost all cases, though, I have found that returning only one error message
at a time (which is what your original approach of returning exceptions on the
setters does) leads to incredible user frustration.  They really want to know
about *everything* they have to fix all at the same time -- otherwise, they are
unlikely to be repeat users of your application if they have any choice in the
matter.

In fact, this is why I use a "form bean" that is separate from the underlying
data objects (EJBs or whatever) -- the purpose of the form bean is to acquire a
semantically correct transaction, which is then processed in an "all or nothing"
manner.  As such, a form bean is really part of the View in an MVC architecture,
and should therefore be designed to meet view-related requirements, not
model-related requirements.

>
> - r

Craig McClanahan