Thanks - I think I finally get it (or though it doesn't feel right though).
Wouldn't it make more sense to have a pre-initialisation action on the action that is actually connected to the form. This pre-initialisation would then populate the form. This would also sort out the problem that I've seen posted about how you would populate multiple forms on one page. I'm sure there is a reason why it doesn't work like this, but I can't see it. -----Original Message----- From: Jim Crossley [mailto:[EMAIL PROTECTED]] Sent: 20 February 2002 18:46 To: Struts Users Mailing List Subject: Re: ActionForm and default values Ian Beaumont <[EMAIL PROTECTED]> writes: > This means that in the action for the "select item" I need to get > hold of the form bean for the next page I'm going to so I can > populate it. You'll need to pass the ID of the selected item to the action. So your "selection view" will have something like this in it: <logic:iterate id="item" name="formBeanName" property="items"> <html:link page="/edit.do" paramId="id" paramName="item"> <bean:write name="item"> </html:link> </logic:iterate> > 1. How do I get hold of the form bean? Do I create it myself? No. The struts controller will create it and pass it to the perform method of an instance of the class identified by the "type" attribute in the "/edit" action in struts-config. That perform method will get the "id" parameter from the request, get the item's values from somewhere and populate the formbean. > 2. This all relies on me knowing the mappings of what page I'm going > to go to next so I can populate the form bean. This defeats the > object of having the struts-XML file. Not exactly. You do have to know which "action" you're going to next, but struts-config allows you to change which classes and views are used to perform that action. And your action class obviously needs to know what kind of formbean to expect so that it can downcast it appropriately, but there's nothing stopping you from casting it to an interface or abstract class which the classes specified in struts-config must implement. You may need that level of "polymorphic flexibility" in your app, but from my experience you won't. > Below is the text from a previous email I sent. The only reply I > got was the example didn't show 'best practises'. In which case, > what is the best practise. The example accounts for a missing "name" attribute in the corresponding action element in struts-config. The best practice is to include a "name" attribute in struts-config so that your action doesn't have to do that. -- Jim -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
