http://tinyurl.com/87fs
What Robert is doing seems like the cannonical solution to me. In many cases just specifying a classname in the configuration wouldn't be enough, and so you need to use reset as well.
The other thing to note is that reset files before any autopopulation takes place.(It's the prepopulation extension point.) Then, if validation, passes, the Action class (if any) fires.
HTH. Ted.
Robert Taylor wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
