Thanks for your reply. Well doing stuff in action is the cleaner approach unless u can use DOM (which is at least quicker). But I solved this by moving the property one level up in the nested hierarchy. Although it doesn't make sense there but it always gets populated before the nested beans. Also since it is a temporary variable you don't need to worry about its placement too much.
I'll look into the other approach when I get some time. Thanks, Affan ----- Original Message ----- From: "Andrew Hill" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Monday, June 02, 2003 4:50 PM Subject: RE: [Nested] Order of Population of nested properties > <snip> > If you must do your thing in the setter then you can use request.getPara... > hmm oops! no you cant. You dont have access to the request object there! > </snip> > > Suppose you could save the reference to the request in a member variable > during the reset() method and refer to it in your setter, but thats > distinctly 'inelegant'. Unless your in a big hurry Id say go with doing the > stuff in the action itself. > > -----Original Message----- > From: Andrew Hill [mailto:[EMAIL PROTECTED] > Sent: Monday, 2 June 2003 19:42 > To: Struts Users Mailing List > Subject: RE: [Nested] Order of Population of nested properties > > > Yeh. There is no gaurantee on the order of population. :-( > > If you must do your thing in the setter then you can use request.getPara... > hmm oops! no you cant. You dont have access to the request object there! > > If its not a multipart form you could do it in the reset() method and use > request.getParameter() to obtain the values you need but I wouldnt normally > recommend that (unless of course you had _already_ created the new rows and > fields on the client side using javascript DOM programming - in which case > you need to create those beans before population occurs!) > > I had to do something similar in my app (simple add rows on submit (no > client side funny business)) so I put the relevant code in the Action that I > was submitting to - which simply checks if the "addMoreStuff" property was > set and adds the necessary rows before forwarding back to the view - (or > takes other action if it wasnt). > > -----Original Message----- > From: Affan Qureshi [mailto:[EMAIL PROTECTED] > Sent: Monday, 2 June 2003 19:35 > To: struts-user > Subject: [Nested] Order of Population of nested properties > > > Hi, > I have an implementation just like the monkey-tree example where I have a > button to add more fields in a form dynamically. The button is a Submit > button which is mapped to a nested bean's property. By default the the > button adds one set of nested (recursively) fields. I want it to add > user-defined no of rows. For that I have a text field mapped to another > property of the same nested bean. I get that value and add the specified no > of rows. It works fine but sometimes I get the following problem. > > Sometimes properties are populated before the other which causes great > confusion. E.g if the 'noOfFieldsToAdd' property is populated after the > 'addMoreFields' (the button) property I wont get the correct output. Also I > see that some properties are populated twice instead of once which is also a > bit confusing. > > Is there any order in which the fields are populated? Can i control this? Or > maybe I am using it in the wrong way? > > Thanks a lot. > > Affan > > > --------------------------------------------------------------------- > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
