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.
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. Bob ----- 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]>
