Hi Johnny, I'm also using label/value vectors. I don't hard-code the form-name. Here are some code snippets:
<!-- Incident form bean --> <form-bean name="incidentForm" type="pwgsc.smis.presentation.maintainHO.IncidentForm"/> <!-- Process an incident request for opening a new or existing incident--> <action path="/incident" type="pwgsc.smis.actions.maintainHO.IncidentAction" name="incidentForm" scope="request" validate="true" input="/incident.jsp" > <forward name="incident" path="/incident.jsp"/> <forward name="unsafe" path="/unsafe.do"/> <forward name="contributing" path="/contributing.do"/> <forward name="hazardous" path="/hazardous.do"/> </action> ............... action class just uses the formbean passed as a parameter. Struts will look for the bean in request scope and use it if it exists. If it doesn't exist it will create. private ActionForward doGet(HttpServletRequest request, ActionForm form) { IncidentForm ifb; ifb = (IncidentForm)form; ifb.setWhatever(....); ...don't know if that is the best way but it does work. We also maintain a transaction object in the session for holding the user data between screens for multiple form updating. -----Original Message----- From: Poon, Johnny [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 9:56 AM To: 'Struts Users Mailing List' Subject: RE: Populating Drop-down Mark, I'm glad you asked the question, caz' I was wondering about the same thing. I'm using label/value. This is what I'm doing. I'm populating a form bean with a vector of label/value option pairs within an Action and store in the request. I then forward it to the targeted JSP, and the <html:select> and <html:optionsCollection> tags within the <html:form> will be populated with the values (label/value) in the vector. I'm able to achieve that and populate my <html:optionsCollection> successfully. However, I am having to hard code the name of the form bean in my Action code. I don't really like it that way, because if I ever change the name of the form bean in the strut-config.xml, I will have to change the Action code as well. Is this a common practice? Does anyone have a better approach, or know what's the best practice regarding this? The following are the simplified code for your reference: strut-config.xml: ================ <struts-config> <form-beans> <form-bean name="baseForm" type="com.forms.BaseForm" /> <form-bean name="stateListForm" type="com.forms.StateListForm" /> </form-beans> <action path="/checkState" type="com.actions.CheckStateAction" name="baseForm" scope="request"> <forward name="selectState" path="/selectState.dhtml" /> <forward name="newBasicQ1" path="/newBasicQ1.dhtml" /> </action> <action path="/enterBasicQ1" type="com.actions.SelectStateAction" name="stateListForm" scope="request"> <forward name="oldBasicQ1" path="/oldBasicQ1.dhtml" /> <forward name="newBasicQ1" path="/newBasicQ1.dhtml" /> </action> </struts-config> CheckStateAction.java: ====================== public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { ActionForward result = null; //To generate the list in the <option> Vector optionVec = StateZipUtil.getStateList(true); StateListForm slf = new StateListForm(); slf.setStateList(optionVec); //This is where I have to make sure the request //attribute name matches the form-beam name: request.setAttribute("stateListForm", slf); return (mapping.findForward("selectState")); } Please let me know if you would like me to clarify anything in my post. Thanks in advance. JP. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 7:44 AM To: Struts Users Mailing List Subject: Re: Populating Drop-down I don't know if it's a best practice or not, but what I do is have the link to the edit screen actually point to an action, which is responsible for initializing any related collections and storing them in session-scoped attributes. A related approach would be to use the <logic:notPresent> tag to check for the collections, and only initialize them when necessary. This has the advantage of dealing with issues such as session timeouts and users accessing the edit screen through other than 'official channels'. HTH, Ian Ian D. Stewart Open Systems Engineer II Enterprise Midrange - Bank One Infrastructure & Operations [EMAIL PROTECTED] (614) 213-6100 "Sinclair, Mark" <[EMAIL PROTECTED]> on 06/10/2003 08:30:00 AM Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Populating Drop-down I am a newbie to struts. This is a simple question and is not totally specific to Struts but is related to the best way to use struts. I am trying to find out what is the recommended approach for populate drop-downs, lists etc? For example say from a simple Logon page I forward to a Supplier List screen displaying all the current suppliers that are stored in the DB. Each supplier in turn is responsible for a certain department (field in department table in DB and departments stored in another DB table). In the supplier list I display the actual department name that they correspond to. Now from selected supplier on list if I go to an editSupplier.jsp I want to give the user the ability to pick a different department from populated list. My question is what is the best way to pass the list of departments to the View (editSupplier.jsp). Should my SupplierForm Bean contain a property eg departments that is an ArrayList or collection of departments in the DB then populate into view using the <html:options> tag? Or if Departments list is used in multiple screens should it be loaded into the session (/request) on logon (or whenever relevant) and use logic:iterate to populate the drop down. I may have a number of these types of drop-down lists, should I just prepopulate them into collections in my "user" session object? How do other people handle this? All examples I have seen just use hard-coded drop-down values in the jsp without retrieval from DB. Any help or pointers much appreciated! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]