I usually give the page with the form it's own action (ie. xxxUpdateSetupAction which I use for stuff like populating lists, etc.) and the target action of the form has it's own seperate action (ie. xxxUpdateAction). In this situation you could set the input attribute of the /xxxUpdate action mapping to /xxxUpdateSetup which then should be executed (forwarded to, this is nice because this way the setup action has access to the posted data) if validation fails. I must say it is just an idea and I haven't had the chance to try it yet, hope it helps.
Dennis "Linus Nikander" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > First off, thank you for the reply. > > As you point out both solutions that you suggest have a certain hackishness > over them it would be nice to avoid. As displaying data from a DB-table, > allowing that data to be edited (en masse, not one record at a time), must > be a pretty common task, doesn't anyone have a more elegant solution when > using struts ? > > //Linus > > > "John M. Corro" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > I've seen two ways of dealing w/ this problem, both of which I see as > 'hackish' > > in nature. > > > > Solution A: > > > > In your getters/setters you implement the following code > > > > public MyCustomBean getMyCustomBean(int index) { > > while(index >= myCustomBeanList.size()) { > > myCustomBeanList.add(new MyCustomBean()); > > } > > return (MyCustomBean)myCustomBeanList.get(index); > > } > > > > In that way you'll never encounter the common IndexOutOfBoundsException. > The > > problem here is that you tend to use alot of hidden fields in your UI to > repopulate > > the data back into the dynamically created beans. > > > > Solution B: > > > > In your reset() method you repopulate your internal Collection of beans. > The > > problem w/ this approach is that often times you have a separate Action > that > > prepopulates your ActionForm. This provides for good separation - the > Action > > is a retriever of a data (nothing more) and the ActionForm is merely a > container > > for data (nothing more). With this approach your ActionForm suddenly > starts > > becoming more intelligent than it really should be. Now it's aware of how > to > > populate itself...not a good thing IMO. > > > > I'd be very interested in hearing other solutions to this problem as I > find > > both of the above solutions cumbersome and hackish and would love to stop > implementing > > them. > > > > >I've been struggling with a problem similar to the one described (and > > >solved) at > > >http://www.mail-archive.com/[EMAIL PROTECTED]/msg50901.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
