Jeff, Sorry that I didn't get back to you earlier, but the fact is that I just didn't have an elegant answer, besides building blank collections based on what you served. Not all that nice, especially when the first bean is done so nicely.
The problem is that when the bean is created when the request comes in, it only knows to make the first bean. When it tries to get at the nested beans & collections, there's none there, and it certainly doesn't know how to create them. If you know the structure, you can build the object tree in the beans constructor, and it works fine. If you don't know the structure, size of lists etc, this then becomes a real hassle. It's fair to assume too, that you're not going to know the extent of the data coming in, or simply it'd be nice to stay flexible, and just have it all happen when the request comes in. It's not really a Struts/BeanUtils problem, as they're only populating what they can get to. You could make sure that there's an object for every index in your list, or key to the map, if you had the "getProperty(int)" style indexed property. But the iterate tag can't use it to do it's business of showing the collection. To help out, I've made a couple of proxy objects that take your original collection, and make sure that the collection is expanded properly, and place-holders are used to store potential positions. You also provide it the class details of the objects to be made in the collections. So when an object is requested at an index, a new one will be made to your specs, and then returned to the BeanUtils for population. Works a treat. I've tried it out on my more-than-complex-enough monkey examples, moving the scope to request, and it all works great. The only thing you have to do, is where you have your collection in your bean, wrap it in these collections (there's one for lists, and one for maps), and pass it the class definition of your clid beans. Also, because the potential is there to have place-holders in the collection (not map, list problem only) when it comes in for use by business logic, you have to call "clean()" on the list collection, to strip out any place-holders that are not required any longer. I've just posted to the commons project for submission, so it still has to go through that process, but I'm putting together some docco whatever the outcome to go on my site etc etc. If you want a go at them without the extra docco (they have a fair bit of javadoc to them), get them from here... http://www.keyboardmonkey.com/next/ReserveMap.java http://www.keyboardmonkey.com/next/ReserveList.java ...you'll have to compile them etc. They're java.util.Map and java.util.List implementations themselves, so you can maintain everything by still coding to the interfaces. They should do what you're after. If not, get back to us... Arron. [EMAIL PROTECTED] wrote: > >Greetings: > I have completed the nested tutorials part one and two (on the >keyboardmonkey site), and actually have no questions about these specifically >because they went as expected and I enjoyed them. >I am new to Struts and would like some clarification on some concepts. I have >done no work with the Struts indexed tags at this time because it appears that >the NEXT tags will do all of that and more. > >I hope I am just missing a simple point. > >1 - I think I am clear on how to represent lists of objects and nested objects >on the page with the tags (it is very easy) but I am not clear on how to >re-build the same object structure when the same page is submitted. > >2 - When I completed the tutorial, I began to alter it in a way to better >represent a format that we will be using on an upcoming project: >- I added created a LoadAction and a Save Action. >- I set the form bean from session to request. >- I removed the sample object creation in the constructors and manually created >the same structure in the Load Action to simulate it coming from the model >layer. >- I grabbed the name of the actionForm from mapping and set it into request >scope. >- The page in rendered as expected. >- And, as I expected, when I submit to the SaveAction, only top level attributes >are populated, without the nested lists . > >So now...... is there an elegant way to rebuild the same structure in the >SaveAction upon submit? > >Thanks all. > > > >-- >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]>
