On Tue, 9 Apr 2002, Bob Lee wrote:
> Date: Tue, 9 Apr 2002 13:53:57 -0500
> From: Bob Lee <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Is FormBean mandatory???
>
> I think I may need to elaborate before I get flamed. I do *not* suggest
> coupling your presentation layer and middle tier with a single value object,
> as it is often the case that your middle tier objects loosely correspond to
> the data submitted in your form if at all; if they are a lot alike, your
> application probably isn't doing much.
>
The form bean and value object bean will be similar in the set of
properties they expose, simply because the UI in many applications
directly mirrors properties in the underlying persistence layer objects.
However, they serve different purposes.
- The form bean is simply the place on the server side to accumulate
the input fields from the screen in an organized way so that you can
validate them. You really don't want to start modifying the underlying
database information until *after* validation has been successfully
completed. Data types (particularly for input fields that are rendered
as text boxes) should be strings so that you can redisplay what the user
typed if they made a mistake. The only logic in a form bean will
typically be the validate() and reset() methods.
- The value object is used to either transport the validated properties
to the underlying EJB or database layer, and/or to abstract away the
details of exactly how persistence is accomplished (so, for example,
you could switch from JDBC calls to EJB if needed later). The data
types in a value object will typically be the same as the underlying
data types stored in the database (int, Timestamp, or whatever).
> I am simply asking why using a separate FormBean is the best solution. It
> seems like an awful lot of work, especially if you are just getting/setting
> Strings.
>
There is a time delay and a feedback loop involved here. Let's see if I
can draw it with ASCII art:
-> Input Form on browser
/ (redisplayed with previous
| data if errors happen)
| |
| | Submit
| v
| Form Bean is reset() and
| then populated (to deal
| correctly with checkboxes)
| |
| | Validate (if not cancelled)
| Error / \
------------ \ Passes
|
Action Called (goes elsewhere
if transaction was cancelled)
|
| Transfer to
| value object
|
v
V.O. sent to the
Persistence Layer
If you skip the form bean, you have lots of undersireable consequences
like updating the value object even when the input data is invalid, not
being able to deal correctly with checkboxes, and inability to deal with
a Cancel button.
If writing form bean classes is burdensome, check out the new
DynaActionFormBean capabilities in the Struts 1.1 beta. Essentially, you
can declare the properties (name and type) in struts-config.xml and you
don't have to write an actual form bean class unless you need custom
reset() or validate() methods -- and even then, you only need to write
those two methods instead of all the property getters and setters.
> Bob
Craig
>
>
> ----- Original Message -----
> From: "Bob Lee" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Tuesday, April 09, 2002 1:40 PM
> Subject: Re: Is FormBean mandatory???
>
>
> > Why is there a need for seperate FormBean object in the View? Couldn't you
> > just use a generic bean that could hold your application-specific
> validation
> > logic and be shared between your view and model? Then, you could
> repopulate
> > the form directly from the request.
> >
> > One problem I see with this is that the names of your form fields and the
> > fields in other parts of your application (i.e. the model) are coupled.
> This
> > is a small sacrifice for the automation you get though and most likely the
> > case for many applications already.
> >
> > Second, you lose field-specific filtering. This isn't such a big deal
> > because you really just need to filter out characters that would interfere
> > with your HTML redisplaying properly anyway which will be the same for
> every
> > field.
> >
> > Lastly, there's the validation. You could go two directions on this one.
> > One, you could have a method built into your domain/value object to
> perform
> > the validation. Struts would handle the String -> Number, etc. conversions
> > automatically returning appropriate error messages. Then, it would call
> your
> > validation method and append those error messages (the automatic
> validations
> > would supercede the manual ones). Admittedly this could get a bit tricky,
> > but it may be better than doing this manually.
> >
> > Or two, the Struts user could implement a FormValidator that would work
> > against a generic value Map interface (in HTTP requests, this would be
> > backed by the HTTPRequest object). You could argue that you lose compile
> > time type checking in this case, but is it really that valuable in the
> > current incarnation?
> >
> > Thanks,
> > Bob
> >
> > ----- Original Message -----
> > From: "Tim Moore" <[EMAIL PROTECTED]>
> > To: "Struts Developers List" <[EMAIL PROTECTED]>
> > Sent: Tuesday, April 09, 2002 11:59 AM
> > Subject: RE: Is FormBean mandatory???
> >
> >
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, April 09, 2002 12:10 PM
> > > To: Struts Developers List
> > > Subject: RE: Is FormBean mandatory???
> > >
> > >
> > >
> > >
> > > On Tue, 9 Apr 2002, Tim Moore wrote:
> > >
> > > > Date: Tue, 9 Apr 2002 11:56:22 -0400
> > > > From: Tim Moore <[EMAIL PROTECTED]>
> > > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > > To: Struts Developers List <[EMAIL PROTECTED]>
> > > > Subject: RE: Is FormBean mandatory???
> > > >
> > > > > -----Original Message-----
> > > > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Tuesday, April 09, 2002 11:38 AM
> > > > > To: Struts Developers List
> > > > > Cc: [EMAIL PROTECTED]
> > > > > Subject: RE: Is FormBean mandatory???
> > > > >
> > > > > On Tue, 9 Apr 2002, Konstantin Priblouda wrote:
> > > > >
> > > > > > Date: Tue, 9 Apr 2002 08:15:03 -0700 (PDT)
> > > > > > From: Konstantin Priblouda <[EMAIL PROTECTED]>
> > > > > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > > > > To: Struts Developers List <[EMAIL PROTECTED]>,
> > > > > > [EMAIL PROTECTED]
> > > > > > Subject: RE: Is FormBean mandatory???
> > > > > >
> > > > > > --- Matt Raible <[EMAIL PROTECTED]> wrote:
> > > > > > > Web forms can only handle Strings and booleans - so
> > > > > > > if your value
> > > > > > > objects have Dates or Integers, get ready for some
> > > > > > > fun!
> > > > > >
> > > > > > Integers are completely OK, floats depend on sanity of
> > > web users.
> > > > > > ( imagine some bank clerk who is used to enter dots to separate
> > > > > > 000... )
> > > > > >
> > > > >
> > > > > Using int or Integer properties in a form bean misses the whole
> > > > > reason for its existence -- to reproduce the user's input in case
> > > > > they made a mistake.
> > > > >
> > > >
> > > > It's still nice that you can use integer properties, though, for
> > > > things like select fields and radio buttons...anything that doesn't
> > > > allow free-form text input.
> > > >
> > >
> > > How do *you* know that your Struts client is actually a
> > > browser (and therefore using the SELECT box to control the
> > > input value that is sent)? It could be a program that is
> > > submitting HTTP requests to trigger transactions in your webapp. :-)
> >
> > Then I'm not concerned about it throwing an exception if I get a garbage
> > value, or maintaining the garbage value for the response. I still do
> > bounds checking of course if that's necessary...it's just nice to have
> > the String to int conversion happen implicitly. Same with booleans and
> > checkboxes.
> >
> > Now I guess if I decide to change my form to use a text input instead of
> > a drop-down, then I have to go back and change the form bean and action.
> > But most of the time, that's not even a remote possibility--like if
> > you're choosing an item from a list and it's sending the primary key
> > back when you submit.
> >
> > In general, though, I don't usually bother making "pretty" error
> > messages for the types of errors that could have only originated from a
> > buggy or malicious client request; I just throw an exception.
> > Presumably the response isn't going to be displayed directly to the user
> > anyway if they're using a GUI client or something like that. Is there
> > any other reason to use only String properties in that case?
> >
> > --
> > Tim Moore / Blackboard Inc. / Software Engineer
> > 1899 L Street, NW / 5th Floor / Washington, DC 20036
> > Phone 202-463-4860 ext. 258 / Fax 202-463-4863
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
