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]
