On May 30, 2013, at 5:42 AM, Miguel Almeida <mig...@almeida.at> wrote: > That's an alternative, yes. I do tend to prefer having the model objects > in my actions though, to keep the number of objects to a minimum - it > makes more sense to have a List<SomeObject> objects than an Integer[] > ids, but maybe that's personal preference.
Of course you eventually want objects, but remember this is a web application, and the only thing the browser is supplying are ids. It's up to your action to bridge that difference. > I'm not sure where the ambiguity is. Take the following request > parameters: > entity.entity2List[0].entity3.id=10 > entity.entity2List[1].entity3.id=20 > > There is no ambiguity in how the Object should be populated - one > entity, which has two Entity2 on the entity2List object: the first > entity2 has an Entity3.id=10 and the second Entity2 has an > Entity3.id=20. Bzzt. That doesn't do what you want, and it requires more data than your browser is providing. That doesn't set the entity3 object with id 10 on the first entity2, rather it assumes there already are two entity2 objects on entity, that those already have entity3 objects on the them and then it just changes the ids! If you model he ui on the browser page differently you can get the parameters above, but the nature of a multi select is that you're getting back multiple (unordered) values each with the same request parameter name. Sounds like what you want are multiple single selects, so that each can have a different description on the page (identifying the entity2 for which this selection is being made), and allowing each to have a distinct index in its parameter name. You'll still have the first problem above, though--you want to load the entity3 with the provided id and set that object on the corresponding entity2. You can probably use the params-prepare-params stack pattern to help you, but you'll still need to have the parameter name be to just to properties on the action that your prepare knows to hydrate on prepare, then the body of the action just has to wire up the objects. -Dale --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
