----- Original Message ----- From: "Paul Smith" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, April 09, 2002 8:48 PM Subject: Re: Is FormBean mandatory???
> This logic is essentially correct in that the framework needs to process > front end stuff prior to mapping to a view object. However, there are good > reasons to not want to have a form bean and a view object and an entity > bean. > > Memory usage -- while frivolous object creation is ok in small to medium > sized apps, larger apps can have thousands of view, form combinations and > object trees. you really dont want to be instantiating a view from the bean > and then a form from the view (even though that may be the purest way to do > it currently) Form beans can be shared by multiple views in a wizard like applications. In particular, we want users to be able to use 'Previous', 'Next', 'Finish', and 'Cancel' buttons to move between screens. Using form beans will save a lot of coding work and these requirements are mandatory regardless how large or small the applications are. > > Ease of development -- dynaForms make for easy form beans but they dont make > for easy mapping from form->validate->view->entity. Also, having to glue all > of that together creates as much confusion as the original type 1 > infrastructures. DynaForm provides a very good starting point for ease of development. People will see an environment soon in which knowledge workers can visually compose Mapping, Model, View, and Controller and then publish the composed mapping. There are visual bindings for properties between the Model (form bean model) and the View (JSP page), also visual bindings for forwards between the Mapping and the Controller. The validations are even simpler: knowledge workers just write the rules right below the property name for which they want to validate on the View. How about the famous reset() function remembering the fact that the knowledge workers do not write single line of the codes? The system will automatically reset unposted properties related to check boxes and select options. These are minor features in our internal systems. Making a tool for the mass is possible on STRUTS infrastructure. > > Maintainability -- the current mechanism is somewhat clugey at best and > results in significant conversion code that has nothing to do with business > logic. Struts as a framework can not overdo its conversion code, but custom conversion code should be able to embed some validation logic inside the converters. However, the current b1 release provides only a runtime exception, ConversionException. I hope STRUTS team could consider a way to have the RequestUtils or RequestProcessor to catch up the business logic conversion exceptions and put them into ActionErrors or forward to an exception handler declared somewhere in the future. > > Design Clarity -- I have spent numerous hours with junior programmers in > code reviews dealing with inconsistent transformation strategies, in > appropriate amounts of object creation, etc. on relatively simple apps. > > Interestingly enough it does create something of an opportunity. Using > proxies and some basic mapping/templating patterns the form bean could be > 'split' to represent a combination of the VIEW and MODEL while maintaining > there relationship and consistency using mapping/validation language in the > config file. Wouldnt that just be cool. Automate the view->form bean up to a > certain point of complexity, and then provide programming hooks for more > robust functionality. Basically there is an opportunity to take struts one > step further by providing apis for app server integration. > > Paul > There are indeed an open space between STRUTS and EJB server. That's the cool part of STRUTS where it keeps itself from touching the EJB at all! There should be a sperate framework or plugable framework that connects the Form Bean and EJB using some kind of mapping technique. Form Beans are very complicated animals: In our system, we allow nested models for the Form Beans, which means the property name a.b[1].c could have 'a' refer to a form bean model property, 'b[1]' refer to a regular bean property, and 'c' refer to another form bean model property again. In the visual presentation of the form bean model, we have check boxes for persistent, populatable, constant. We also make distinct concepts between populating a property and assigning a property to a form bean. We even have a concept (anolog to EJB) for container managed form bean persistency for benifits of knowledge workers. As a result, another feature is that we allow knowledge workers to replay the wizard like applications exactly the same sequence they did two months ago. Form beans are at the center stage for such the business logics here. I think STRUTS team should have a very deep understanding of this animal before connecting STRUTS to EJB. My prediction to Form Bean is that it will share equal or more popularity as Entity Bean or Session Bean in the future. > > ----- Original Message ----- > From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > To: "Struts Developers List" <[EMAIL PROTECTED]> > Sent: Tuesday, April 09, 2002 2:52 PM > Subject: Re: Is FormBean mandatory??? > > > > > > > > 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]> > > > > > > > -- > 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]>
