Robert,
What you are saying makes perfect sense. You subclass the dyna form and
provide an implemtation of the LazyList, about the same as we would do with
an ActionForm based solution.
Do you have a single dyna form subclass or multiple? For example, in our
app, we have 8 objects that are used as indexed properties across our
various editors. In such a situation, would you have a single subclass
that would provide the factory definitions for each of the objects, or
would you have multiple subclasses that would each provide the factory
definitions that the form was responsible for?
In case I'm not clear in my question, if you had a:
(1) Family Editor that allows the user to manage a collection of
FamilyMember objects. I would have a FamilyForm with a collection of
FamilyMemberForm objects supported by LazyList.
(2) FamilyMember editor that allows the user to manage a collection of
favorite meals. I would have a FamilyMemberForm with a collection of
FavoriteMeal objects supported by LazyList
Would you have two subclasses of dyna form or just one with both
collections being set up in the reset method.
Nick
|---------+---------------------------->
| | "Robert Taylor" |
| | <[EMAIL PROTECTED]|
| | .com> |
| | |
| | 12/11/2003 08:52 |
| | AM |
| | Please respond to|
| | "Struts Users |
| | Mailing List" |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
|
| cc:
|
| Subject: RE: dynamically sized form (mostly solved)
|
>------------------------------------------------------------------------------------------------------------------------------|
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]
