One possible solution is to use one form bean and in your action, if you see the form isn't populated, forward to the jsp action which either populates it or gives you enough information to populate it other ways.
Edgar -----Original Message----- From: Sri Sankaran [mailto:Sri.Sankaran@;sas.com] Sent: Tuesday, November 12, 2002 10:56 AM To: 'Struts Users Mailing List' Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) No sweat. The reason this discussion got so off whack was because I tried to slam a square peg in a round hole by continuing with Kris' example (Edit & Save actions) to make my point -- bad idea. So what *is* my scenario? Consider for example, a master-detail pair of pages. The master page display a list of employee names. The detail page -- which is displayed when a user selects an employee from the master page -- displays a collection of (possibly editable) fields that describe the selected employee. The form-bean associated with the detail page is your typical EmployeeBean object. Even if the struts-config is set up with the right action mapping like <action path="/detail" type="com.acme.DetailAction" name="employeeBean"/> how can Struts know that the user selected the user 'John Smith' on the master page? Ergo, the need to create the necessary form bean in the action for the master page. We cannot wait for/depend on Struts to create it. I don't like the fact that the MasterAction needs to have knowledge of the requirements for the detail page (the type of bean, the name under which it is accessed) -- or maybe that isn't so bad....?? Are you telling me that I missed something fundamental to Struts?...'tis quite likely. Sri -----Original Message----- From: Eddie Bush [mailto:ekbush@;swbell.net] Sent: Tuesday, November 12, 2002 11:34 AM To: Struts Users Mailing List Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) Struts can't divine it! HEH - it's good, but it's not that good. You have to tell it. If I said something that got misunderstood as what you're saying I apologize. You are exactly correct - the business logic is the only thing that can make the determination. Sri Sankaran wrote: >Yes! Finally someone who sees what I am talking about! > >*That's* exactly the scenario I am talking about. I can't see how >Struts can divine what values the form-bean property needs to be >initialized. It is predicated by the preceding business logic. > >Sri > >-----Original Message----- >From: Martin Cooper [mailto:martin.cooper@;tumbleweed.com] >Sent: Monday, November 11, 2002 9:40 PM >To: 'Struts Users Mailing List' >Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() >for m confusion) > > >I think you missed the point here, Eddie (or perhaps I missed that you >didn't miss the point :). > >Think about it this way. Struts will create your form bean >automagically in a couple of cases: when it needs to populate one from >an incoming request, and when it needs to render a form but can't find >the corresponding form bean. > >Now consider the case where you need to populate the form with some >values that the Action came up with somehow. You'd do that by having >the values in the form bean properties, right? That way, the Struts >HTML tags will do the work for you. > >But now consider the case where you haven't yet invoked anything in the >app that would cause the appropriate form bean to be instantiated. The >action that came up with the values might have been invoked with a >different form bean, or perhaps no form bean at all. So Struts hasn't >instantiated the bean yet. Struts *will* instantiate the bean when it >the <html:form> tag is processed, but by then, it's too late for the >Action to populate the form bean. > >So the only way for the action to pre-populate the form bean, so that >those values are picked up by the Struts HTML tags to populate the form >is for the action to instantiate the form bean itself. > >One way of creating the form bean is RequestUtils.createActionForm(). > >-- >Martin Cooper > >>Why bother specifying a form-bean in your config file if you're going >>to create it yourself? Yeah there's some validation that can be >>done on it >>by Struts - but if you don't specify a form-bean for an >>action-mapping >>(you specify nothing for the action-mapping's name attribute) I don't >>believe that validation is done (why would it be? Struts >>doesn't know >>there's a form being used for this action!). Hrm - in fact >>you lose a >>great deal of the utility Struts provides if you don't make this >>association. Think about it: You have to tell Struts what type your >>form is of - so it can instantiate it. It needs this >>information for no >>other purpose. It could easily tell later on that the form is of the >>wrong type for validation etc. Also, you could specify by >>the attribute >>property the name of a form which you instantiated yourself. You >>*could* (if you wanted to) cut yourself off from the Struts form >>mechanism altogether. >> >>What I suggest in no way impacts your ability to use good design >>(delegates etc). It just takes one very mechanical thing out of your >>hands - and out of your concern - and "just does it". It's solid. It >>works. If it ever fails you *please* file a bug! It also >>has no impact >>on where data comes from or where it goes to. You can pass >>data via a >>form from one action to another in about 2 ways that come to mind >>immediately: 1) session-scoped form 2) using hidden fields. >>I'm sorry, >>but I think you misunderstood my entire argument. My >>appologies for not >>having been clearer. >> -- Eddie Bush -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org> -----Original Message----- From: Eddie Bush [mailto:ekbush@;swbell.net] Sent: Tuesday, November 12, 2002 11:34 AM To: Struts Users Mailing List Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) Struts can't divine it! HEH - it's good, but it's not that good. You have to tell it. If I said something that got misunderstood as what you're saying I apologize. You are exactly correct - the business logic is the only thing that can make the determination. Sri Sankaran wrote: >Yes! Finally someone who sees what I am talking about! > >*That's* exactly the scenario I am talking about. I can't see how >Struts can divine what values the form-bean property needs to be >initialized. It is predicated by the preceding business logic. > >Sri > >-----Original Message----- >From: Martin Cooper [mailto:martin.cooper@;tumbleweed.com] >Sent: Monday, November 11, 2002 9:40 PM >To: 'Struts Users Mailing List' >Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) > > >I think you missed the point here, Eddie (or perhaps I missed that you >didn't miss the point :). > >Think about it this way. Struts will create your form bean >automagically in a couple of cases: when it needs to populate one from >an incoming request, and when it needs to render a form but can't find >the corresponding form bean. > >Now consider the case where you need to populate the form with some >values that the Action came up with somehow. You'd do that by having >the values in the form bean properties, right? That way, the Struts >HTML tags will do the work for you. > >But now consider the case where you haven't yet invoked anything in the >app that would cause the appropriate form bean to be instantiated. The >action that came up with the values might have been invoked with a >different form bean, or perhaps no form bean at all. So Struts hasn't >instantiated the bean yet. Struts *will* instantiate the bean when it >the <html:form> tag is processed, but by then, it's too late for the >Action to populate the form bean. > >So the only way for the action to pre-populate the form bean, so that >those values are picked up by the Struts HTML tags to populate the form >is for the action to instantiate the form bean itself. > >One way of creating the form bean is RequestUtils.createActionForm(). > >-- >Martin Cooper > >>Why bother specifying a form-bean in your config file if you're going >>to create it yourself? Yeah there's some validation that can be >>done on it >>by Struts - but if you don't specify a form-bean for an >>action-mapping >>(you specify nothing for the action-mapping's name attribute) I don't >>believe that validation is done (why would it be? Struts >>doesn't know >>there's a form being used for this action!). Hrm - in fact >>you lose a >>great deal of the utility Struts provides if you don't make this >>association. Think about it: You have to tell Struts what type your >>form is of - so it can instantiate it. It needs this >>information for no >>other purpose. It could easily tell later on that the form is of the >>wrong type for validation etc. Also, you could specify by >>the attribute >>property the name of a form which you instantiated yourself. You >>*could* (if you wanted to) cut yourself off from the Struts form >>mechanism altogether. >> >>What I suggest in no way impacts your ability to use good design >>(delegates etc). It just takes one very mechanical thing out of your >>hands - and out of your concern - and "just does it". It's solid. It >>works. If it ever fails you *please* file a bug! It also >>has no impact >>on where data comes from or where it goes to. You can pass >>data via a >>form from one action to another in about 2 ways that come to mind >>immediately: 1) session-scoped form 2) using hidden fields. >>I'm sorry, >>but I think you misunderstood my entire argument. My >>appologies for not >>having been clearer. >> -- Eddie Bush -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
