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