Nicholas,
I use DynaActionValidatorForm almost exclusively in my application.
I have successfully used IndexedProperties for structures that are dynamic
using LazyLists.
For me, when ever I have to do this, I always have to think about how Struts
handles the sequence of events in a request and submission.
What I do is subclass DynaActionValidatorForm and override the reset().
The reset() gets called before the action is executed.
For example:
/**
* Reset all bean properties to their default state. This method is
* called before the properties are repopulated by the controller servlet.
* <p>
* The default implementation uses the initial value specified in the
* FormPropertyConfig element for each property.
*
* @param mapping The mapping used to select this instance
* @param request The servlet request we are processing
*/
public void reset(ActionMapping mapping, HttpServletRequest request) {
super.reset(mapping, request);
/*
* We have to create lazy lists for selected items
* because we don't know which items will index
* into the collection. A lazy list will create
* the appropriate item at a specified index if it
* doesn't exist there.
*/
List selectedItems = ListUtils
.lazyList(new ArrayList(), new SelectedItemFactory());
this.set("selectedItems", selectedItems);
// other stuff here if necessary
}
My XXXXFactory classes are usually inner classes to the subclassed
Dyna*Form.
For example:
/**
* <code>SelectedItemFactory</code> is used in the form
* to create a lazy list that will lazily create selected items.
*
* @author Robert Taylor
* @author last modified $Author: rtaylor $
* @version $Revision: 1.8 $ $Date: 2003/11/17 13:58:51 $
* @see org.apache.commons.ListUtils
*/
class SelectedItemFactory implements Factory {
/**
* Create a new instance of the specified object
*/
public Object create() {
return new SelectedItemVO();
}
}
As long as the input fields which are added to the client have the correct
syntax
for indexing into your form (formName.selectedItems[0].fieldName) then
Struts should
handle the rest.
Does that help at all?
robert
> -----Original Message-----
> From: Nicholas L Mohler [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 11, 2003 7:46 AM
> To: Struts Users Mailing List
> Subject: Re: dynamically sized form (mostly solved)
>
>
>
>
>
>
>
> Ted,
>
> The origin of this thread had to do with using Indexed Properties and a
> Dyna* form. As when using the ActionForm, getting the values to the
> browser is not an issue. The area where the difficulty arises is when the
> values are returned from the browser.
>
> When using the ActionForm (or subclass), this is neatly handled by
> implementing the LazyList (or similar functionality) or by making the form
> have session scope. Note that the session scope solution fails if the
> end-user can add new entries to the list without a call to the server. In
> the app I work on, we use javascript to add and remove list
> elements, so we
> use LazyList functionality.
>
> The problem is when the Dyna* type forms are used. How do the indexed
> properties get back into the form when the page is submitted. Similar to
> ActionForm based implementations, the form can have session
> scope, but this
> also fails if the user can add new entries to the list without a server
> call. It isn't obvoius how one would implement LazyList type
> functionality
> in a dyna form.
>
> I have seen the suggestions for map-backed forms, but I don't see how this
> would help for the indexed properties...how it would be different
> from just
> grabbing the indexed properties out of the request.
>
> Any thoughts on this?
> Nick
>
>
>
>
>
>
> Ted Husted
>
> <[EMAIL PROTECTED] To: Struts
> Users Mailing List <[EMAIL PROTECTED]>
> g> cc:
>
> Subject: Re:
> dynamically sized form (mostly solved)
12/11/2003 07:03
> AM
>
> Please respond to
>
> "Struts Users
>
> Mailing List"
>
>
>
>
>
>
>
>
>
> I've lost track of the underlying use case for this thread, but if it's
> about populating input options on a form, you might consider using a
> second object for storing these types of options. For a time, some of us
> were starting to use the ActionForm to represent the input options along
> with the input values. This notion had more to do with code maintenance
> than architecture. At this point, I would suggest using finely-grained
> DynaActionForms to represent only the input required by an action. All
> other constructs, like arraylists for select boxes and so forth, can be
> put on a second "chrome" bean. A distinct advantage here is that you can
> scope the chrome bean as appropriate. A global default can live in
> applidcation scope, and other can live in session or request scope, as
> appropriate to a request.
>
> HTH, Ted.
>
> Andy Schmidgall wrote:
> > Does this mean it's impossible to do through request scope? I am
> > attempting to do this, and it would be nice to know if my work is in
> > vain :)
> >
> > -Andy
> >
> > -----Original Message-----
> > From: Yee, Richard K,,DMDCWEST [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 10, 2003 3:20 PM
> > To: 'Struts Users Mailing List'
> > Subject: RE: dynamically sized form (mostly solved)
> >
> >
> > I thought it worked, but it didn't.
> >
> > -Richard
> >
> > -----Original Message-----
> > From: Nifty Music [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 10, 2003 1:02 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: dynamically sized form (mostly solved)
> >
> >
> > Nicholas,
> >
> > What you said definitely makes sense to me. Richard graciously replied
> > off-list with a similar response. I remember reading documentation
> > which stated that when using dynamic arrays with DynaForms, it is
> > necessary to place the DynaForm in session scope. However, I 'm almost
> > positive that someone (Matt? Mark?) mentioned on this list that they
> > were able to pass an ArrayList through a DynaForm in request scope. For
> > a variety of reasons, I'm not too eager to put the entire formbean in
> > the session for the sake of propogating one ArrayList attribute. If
> > Matt or Mark or anyone else has some insights to share regarding how
> > they were able to get this to work in request scope, I'd be very
> > grateful to hear.
> >
> > Thanks again,
> >
> > Brent
> >
> >
> > ---------------------------------------------------------------------
> > 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]
