Wow. You're using the <nested> tags for this form, right? I haven't tried this yet, but there's a chance you might be able to define a form with a field that matches FooBar:
class MyForm { FooBarForm fooBar; // then you'll have your accessors, of course class FooBarForm { Integer id; String value; String type; Collection fooBars; // define accessors /** no-arg constructor */ FooBarForm () { fooBars = ListUtils.lazyList(new ArrayList(), new Factory() { public Object create() { return new FooBarForm(); } }); } } } I think (at least in theory) that BeanUtils will be able to handle this bean. You'll be passing it MyForm.fooBar instead of MyForm itself. If you decide to try this, could you share the results? :) Hubert On Wed, 15 Sep 2004 18:01:26 -0400, Rick Reumann <[EMAIL PROTECTED]> wrote: > This app I'm working on is sort of any odd beast. It's a case where the > resulting JSP is going to be built by generic beans that are nested > inside of the same type of generic bean etc. So for an example ... > > class FooBar { > Collection fooBars; > Integer id; > String type; > String value; > //set/gets > } > > So what happens is you can have Collections of these beans nested > serveral levels and you don't know before run-time how deep. > > My form will need to display everything and capture any changes to the > 'value' field. > > So my ActionForm (in this example) would only have one main property: > > private FooBar fooBar; > > When the form submits it captures all the nested fooBar information. > > The problem of course is making sure you don't get those nasty BeanUtils > index errors when the form submits. > > Typically, for standard applications, I'd use ListUtils.lazyList for my > Collections. The problem, though, here is that you don't know how deep > the Collections go (without a call to the business layer). > > The only way I've found to get this type of form to work is to give it > Session scope. Everything is fine then since it retains the initial > FooBar object placed in the form that is done in a 'setUp' or 'prep' > method before the form is displayed for the user. > > Just wondering if there is another approach I could consider to tackle > this without using the Session. I think in this case the Session holds > the most promise. > > -- > Rick > > --------------------------------------------------------------------- > 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]