As long as your reset method is coded properly, all of you values should be retained. Pre-populating from a bean does not break the MVC because that is exactly how you display dynamic data which is not in a form. I am doing this and it works fine for me.
JC -----Original Message----- From: Ian Beaumont [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 3:10 AM To: 'Struts Users Mailing List' Subject: RE: How do I init a Form bean via business logic? I've been trying to get an answer to how to initialise a form bean from this list, but with no success. See "Re: Can this be done at all using Form objects within struts fram ework" The reason why I don't think you can pre-populate a form from the beam (other than possibly breaking MVC) is that if the form fails to validate correctly, when it is re-displayed it will wipe out all values the user has entered - which wouldn't be the desired behaviour. Can someone please give some guidance to the best practise for this initialising a form bean via business logic. -----Original Message----- From: Barr, Scott [IBM GSA] [mailto:[EMAIL PROTECTED]] Sent: 20 February 2002 03:27 To: 'Struts Users Mailing List' Subject: RE: How do I init a Form bean via business logic? The best reason I can give as to why you should use form objects, is that you will pretty much always provide String getter and setters, rather than the 'real' data object types. eg Timestamp > -----Original Message----- > From: Jakkampudi, ChandraseKhar [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, February 20, 2002 1:03 PM > To: 'Struts Users Mailing List' > Subject: RE: How do I init a Form bean via business logic? > > Scott, > I need to clarify this further. > I am not suggesting you do away with an action. You use the action to get > the data that is required as a value object. Since this is a value object, > it can be re-used to serve another client. Instead of creating a form bean > in the action, you set the retrieved value object from your DAO as a bean > in > your request. Thus, you avoid additional mapping code like > form.setValue(valueObject.getValue()) and so on. > Then if need be, you pre-populate the form, or display the data outside of > the form in the jsp as a table or what not. > > An instance of where this would be particularly useful. Let us say that > some > fields are not editable but are display only. (like your ID). Initializing > the form in the action causes part of your display to be populated from > the > action while the rest is in the jsp. > > Your argument about jsp not creating and initialising objects is not true > because that is exactly what jsp:useBean, bean:define and other tags > (which > is the "right" way to do things) do. Also, if you do not initialise a form > in the action, or dont need to pre-fill data, the jsp IS the place where > these objects are created. > > Nothing in what I suggested, implies that you need to catch errors and > exceptions in the jsp. I agree with you that they shouldn't and with the > approach I outlined they dont have to. All of this is done in the action. > I > am only asking about the additional step of creating the form bean which I > think is not necessary. > > The action creates the Business Objects. You are right. But it does not > NEED > to create the Form objects. It can. But I cannot see an overriding reason > why it SHOULD. > > > Thanks > JC > > > > -----Original Message----- > From: Barr, Scott [IBM GSA] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 19, 2002 7:47 PM > To: 'Struts Users Mailing List' > Subject: RE: How do I init a Form bean via business logic? > > > > 1. If you are doing something other than creating a new view component and > allowing it to set its own default values, I would imagine that you are > doing an Action. > > 2. No it doesn't break MVC if the Action initialises the Form. If an > action > cannot deal with a form, where exactly is this supposed to be performed? > An Action populating a form object does not mean it requires knowing how > the > data will be presented, it is just data. What the jsp does with it is not > the concern of the action. The Action does not care if property X is > displayed as static text, or in a text field. > The jsp is a presentation layer, and should not be creating and > initialising > objects. By the time you get to your presentation layer, you should not > have > to be catching errors, and redirecting to error pages etc. > The Action creates business objects. These objects can throw exceptions. > eg. > error while getting a new ID from a database. If an error occurs, I add > error to the errors, and this will be displayed... > If you init a Form bean in a jsp, and an exception occurs, you must deal > with it in the page. > > 3. What additional code? If your action deals with your business layer, > but > should not contain business logic itself. If it does, you cannot use your > business object model to provide a different interface > > 4. I don't see that filling a jsp with debug code makes for easier > debugging. > If something is populated incorrectly, you would look at your Action > object. > I have toString() method in my business objects, and these objects log to > file. Each layer provides its own logging (I'm using log4j), so while > developing I can switch log levels quite easily. > Once a layer is debugged, I shouldn't have to debug it from a different > layer. This makes for simple unit testing, and does away with the need for > a > gui debugger > > Scott > > > -----Original Message----- > > From: Jakkampudi, ChandraseKhar [SMTP:[EMAIL PROTECTED]] > > Sent: Wednesday, February 20, 2002 11:36 AM > > To: 'Struts Users Mailing List' > > Subject: RE: How do I init a Form bean via business logic? > > > > My reasons are as follows. I do not know if they are right or wrong, but > > would appreciate comments. > > > > 1. Consistency. All of the dynamic data that is presented in a jsp is > via > > bean:write tags or scriptlets which access a value object. I think > > pre-populating or initializing a form should be no different. > > 2. Breaks MVC(IMHO). Action is a controller component. Initialization of > > forms is a presentation issue. > > 3. Additional code. A value object is generated anyway by the DAO(which > > you > > use to get the data). If you use the action for initialization, all you > > are > > doing is copying the data into the form bean. It ensures clean > separation > > of > > data when you do it the other way around (i.e copying data from form > bean > > to > > value object even if they are similar) because you do not want the rest > of > > your code to know about action forms etc which are html specific. But it > > does not make sense (to me) to copy pure java objects/value beans into > > identical form beans just for pre-population. > > 4. Easier debugging. If your value is populated wrong, you can look at > the > > jsp to figure out which values are being written from which bean. If you > > do > > init in the action, you have to debug java code to find out presentation > > issues especially for things like multiple selects of dropdowns etc. > > > > Again, I am not saying init in the action is wrong. But I saw a lot of > > emails saying that it is the right thing to do without giving any > reason. > > For the above mentioned reasons, I opted not to do the init in the > action. > > I > > am trying to understand why this approach is recommended over the other > > one? > > What have I missed? > > > > TIA, > > JC > > > > -----Original Message----- > > From: Barr, Scott [IBM GSA] [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, February 19, 2002 6:45 PM > > To: 'Struts Users Mailing List' > > Subject: RE: How do I init a Form bean via business logic? > > > > > > > > Hi JC > > > > If the data is dynamic, and we are talking about web apps here, why not > > populate it in the action? > > The form is a view component, and I don't give it any more 'smarts' than > > is > > possible. This as a neat way of separating the layers your application, > > one > > of the benefits of clean MVC design > > > > Scott > > > > > -----Original Message----- > > > From: Jakkampudi, ChandraseKhar [SMTP:[EMAIL PROTECTED]] > > > Sent: Wednesday, February 20, 2002 10:59 AM > > > To: 'Struts Users Mailing List' > > > Subject: RE: How do I init a Form bean via business logic? > > > > > > Why should pre-populating a form be done in the preceding action? When > > you > > > want to display some dynamic info. say in a table you put a value bean > > in > > > the request or session and use bean:write etc to display. Why should > the > > > same not apply to form beans? Why not use the value attribute of the > the > > > html tag libraries to pre-populate the data? I have seen posts saying > it > > > should not be done this way but no reasons are given. > > > > > > What I mean is: > > > <html:text property="data" value="<%=bean.getData()%>"/> is a valid > way > > to > > > populate the form (as long as the bean is in request scope and not > > session > > > or application scope) > > > > > > why is the above not recommended or preferred? > > > > > > > > > > -- > > 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]>
