Yeah, I've done this stuff a fair bit. You definitely need 1.1 because the "indexed" attribute has been added to the <html:xxx> tags and the nested extension has been folded into the core distribution.
You can definitely declare an array or ArrayList of objects as a form-property of a DynaActionForm. The objects in the lists I use are regular beans with getter/setters since I haven't gotten around to figuring out how to nest DynaActionForms in such a way as to have the controller handle population for me. Anyway, it definitely works with the custom beans I define as ad hoc classes-- the controller can populate any bean so long as it can find the class that defines it. You define the form elements on the JSP doing the submission using logic:iterate and the "indexed" attribute of your <html:xxx/> tags. My rule is to use indexed tags with one dimension of arbitrary length and nested with more than that and never both-- noone to my knowledge has yet contradicted me in this forum so I think it's reasonably good rule of thumb. In general, this approach is *way* better than parsing the request attributes in your code. Let me know if I'm not clear-- it is after all Friday-- but anyway it's totally do-able. The problem I've had is with elements like checkboxes that require some activity in the reset() method. Since you're building an array dynamically from the DB you have to work out some strategy for handling exceptions that leave your form less than totally initialized. I'm thinking I could do something with declarative exceptions, but again I haven't gotten around to it. -----Original Message----- From: Mark Silva [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 10:28 AM To: Struts Users Mailing List Subject: RE: Design Problem: Multiple Object Update you still need to declare your variables in the config file eith a DynaActionForm. This form is dependent on whats in the db at that time. does any one else have any suggestions for this design issue? thanks, mark -----Original Message----- From: Galbreath, Mark [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 10:27 AM To: 'Struts Users Mailing List' Subject: RE: Design Problem: Multiple Object Update Oh...have you looked into DynaActionForm? -----Original Message----- From: Mark Silva [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 1:22 PM To: Struts Users Mailing List Subject: RE: Design Problem: Multiple Object Update Mark, I dont think you really read my email before responding. I understand the importance of the Form Action Paradigm, and why it exisits. I am using it in most places in my application. In this particular form, I have a list of objects, with multiple attributes. Each attribute name is preceded by the objects id. this list is dynamically created, so i would not know how to create the form beforehand. I was wondering if there was some struts feature that could help me with the semi-common wbe form problem. any ideas? thanks, mark s. -----Original Message----- From: Galbreath, Mark [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 10:19 AM To: 'Struts Users Mailing List' Subject: RE: Design Problem: Multiple Object Update I was only suggesting upgrading. By bypassing the ActionForm you do not allow Struts to do what it does best - set the state of a bean with values gathered from an HTML form upon submit. Your users are not really updating dynamically - that would mean in real time. They are inputting values into a form and then submitting the form. If you have an Action class and ActionForm declared and mapped in struts-config.xml, Struts will set the state of all associated variables in the ActionForm (JavaBean) automatically. Then you can use the associated Action class to do whatever you want with the values - store in a database, pass to another action, return to the user for verification, etc. Mark -----Original Message----- From: Mark Silva [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 12:52 PM How will upgrading to 1.1b2 help me here? does it provide some feature that does what i need? i cannot seem to find it. i understand i shouldn't bypass the form, but HOW can i avoid it since these are all dynamically created inputs based on an id list? thanks, mark -----Original Message----- From: Galbreath, Mark [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 4:29 AM To: 'Struts Users Mailing List' Subject: RE: Design Problem: Multiple Object Update a. upgrade to 1.1b2 b. don't bypass the ActionForm -----Original Message----- From: Mark Silva [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 8:40 PM To: Struts Users Mailing List Subject: Design Problem: Multiple Object Update How would you strut gurus approach this in a Struts oriented way ( I am currently using Struts 1.0.2) I have a list of objects on the screen, and i want to be able to make mass updates to. For example, i have a list of users, with Various Attributes (name, isActive checkbox, etc). I want the user to be able to make edits on the whole screen, and then submit it. What is the best way to keep the data together in terms of naming of the fields. currently I precede each value with the userId and an underscore. User = Mark Silva userId = 101 name field --> 101_name isActiveField --> 101_isActive then to get all the data, i have to parse through the parameter list in the request, and piece this all together. Notice I am bypassing the Form object. Is there a Struts way to do this? thanks, Mark -- 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
