You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Nate Bowler <bo...@attask.com> on 2003/07/08 17:14:19 UTC
Best Practice Mapped/Indexed Properties on an ActionForm
I put out another similar post, but let me ask this question another way in
hopes of generating more feedback.
I have an application with many forms that contain dynamic lists of
elements. For example, rows of elements that contain a checkbox, select
list, and 2 text boxes for each element.
In traditional JSP design, normally I would create a loop and name these
elements "rowbox1", "rowselect1", "rowtext1", "rowtext21", ...
"rowbox(n)"...etc. At any rate, you get the idea; we've all done this.
With struts, you have the mapped and indexed property syntax that works
great for pre-populated forms. For example, I can have an "open" action that
pre-populates an ActionForm with all the nested data and forward to a JSP
that allows editing. Everything looks great.
The PROBLEM is submitting this form. I haven't found a way to make Struts
auto-allocate space in a collection (or a Map, for that matter) in an
ActionForm for the submit action. Almost every example on this I've seen
deals with a fixed number of elements, and most of these still focus on the
pre-populate action. These examples completely avoid this issue.
So, when the number of elements on the form VARIES, what is the "best
practice" in design for this? I'm talking about an indexed or mapped
collection that contains other Java Beans. How can you get these to submit
properly into an ActionForm? If there are options, can you weigh the
pros/cons of each?
For example, I'm sure a session-scope bean would accomplish this, but I stay
away from session-scope beans because of clustered deployment issues. I
would imagine a hidden value giving the length might be useful, but I'm not
sure where in the ActionForm's initialization sequence it could be used.
Perhaps I need to do something different in the reset() method? Are there
other options?
Nate
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Best Practice Mapped/Indexed Properties on an ActionForm
Posted by Nate Bowler <bo...@attask.com>.
Yours and Michael's suggestion are similar and will likely be the approach I
will take. I'll probably just use the ListUtils.lazyList(List, Factory)
decorator to create the autovivifyingList.
What's surprising to me is that this seems like an extremely common use
case, but it isn't clearly mapped out in the Husted book or in the online
docs. I'm sure many developers want to retain an object structure for forms
that contain dynamic lists of data, and using commons-collections lazyList()
would seem like a good documentation example to provide (assuming this
works, of course, as I have not yet implemented it).
At any rate, thanks for the reply.
Nate
-----Original Message-----
From: Justin Hickman [mailto:jhickman@mpowercom.com]
Sent: Tuesday, July 08, 2003 10:23 AM
To: Struts Users Mailing List
Subject: Re: Best Practice Mapped/Indexed Properties on an ActionForm
Nate,
I ran into that same problem a couple of weeks ago. The
solution that we came up with was to create an AutovivifyingList
object.
Basically, with the AutovivifyingList object, we have extended
java.util.ArrayList and added functionality to allow for
autovivifying objects.
When struts tries to populate indexed objects from a form, it
will do something like: form.getList(1).setFooBar("value"); It
has a problem when it does "form.getList(1)" because the list
does not exist with any objects in that index. To avoid this,
we have the overridden method "public Object get(int)" and
instantiated the appropriate object if it didn't exist and would
return it instead of null.
Of course, you would have to have constructors to the
AutovivifyingList object that takes in a class object of the
class you want instantiated on a get, and you would also need to
tell it if you should instantiate intervening objects (for
example, if you do a getList(5) and 1-4 doesn't exist, you can
tell it to create all intervening or leave them null)
That's the basic idea behind it. Of course there are many ways
to implement it. This, however, is how we handled the issue of
request scoped indexed forms.
I hope this helps. If you need a more concrete example, let me
know.
Thanks,
--
Justin Hickman
Software Engineer
Network Support Systems, Information Technology
Mpower Communications Corporation
At 2003-07-08T15:14:19Z, "Nate Bowler" <bo...@attask.com> writes:
> I put out another similar post, but let me ask this question another way
in
> hopes of generating more feedback.
>
> I have an application with many forms that contain dynamic lists of
> elements. For example, rows of elements that contain a checkbox, select
> list, and 2 text boxes for each element.
>
> In traditional JSP design, normally I would create a loop and name these
> elements "rowbox1", "rowselect1", "rowtext1", "rowtext21", ...
> "rowbox(n)"...etc. At any rate, you get the idea; we've all done this.
>
> With struts, you have the mapped and indexed property syntax that works
> great for pre-populated forms. For example, I can have an "open" action
that
> pre-populates an ActionForm with all the nested data and forward to a JSP
> that allows editing. Everything looks great.
>
> The PROBLEM is submitting this form. I haven't found a way to make Struts
> auto-allocate space in a collection (or a Map, for that matter) in an
> ActionForm for the submit action. Almost every example on this I've seen
> deals with a fixed number of elements, and most of these still focus on
the
> pre-populate action. These examples completely avoid this issue.
>
> So, when the number of elements on the form VARIES, what is the "best
> practice" in design for this? I'm talking about an indexed or mapped
> collection that contains other Java Beans. How can you get these to submit
> properly into an ActionForm? If there are options, can you weigh the
> pros/cons of each?
>
> For example, I'm sure a session-scope bean would accomplish this, but I
stay
> away from session-scope beans because of clustered deployment issues. I
> would imagine a hidden value giving the length might be useful, but I'm
not
> sure where in the ActionForm's initialization sequence it could be used.
> Perhaps I need to do something different in the reset() method? Are there
> other options?
>
> Nate
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Best Practice Mapped/Indexed Properties on an ActionForm
Posted by Justin Hickman <jh...@mpowercom.com>.
Nate,
I ran into that same problem a couple of weeks ago. The
solution that we came up with was to create an AutovivifyingList
object.
Basically, with the AutovivifyingList object, we have extended
java.util.ArrayList and added functionality to allow for
autovivifying objects.
When struts tries to populate indexed objects from a form, it
will do something like: form.getList(1).setFooBar("value"); It
has a problem when it does "form.getList(1)" because the list
does not exist with any objects in that index. To avoid this,
we have the overridden method "public Object get(int)" and
instantiated the appropriate object if it didn't exist and would
return it instead of null.
Of course, you would have to have constructors to the
AutovivifyingList object that takes in a class object of the
class you want instantiated on a get, and you would also need to
tell it if you should instantiate intervening objects (for
example, if you do a getList(5) and 1-4 doesn't exist, you can
tell it to create all intervening or leave them null)
That's the basic idea behind it. Of course there are many ways
to implement it. This, however, is how we handled the issue of
request scoped indexed forms.
I hope this helps. If you need a more concrete example, let me
know.
Thanks,
--
Justin Hickman
Software Engineer
Network Support Systems, Information Technology
Mpower Communications Corporation
At 2003-07-08T15:14:19Z, "Nate Bowler" <bo...@attask.com> writes:
> I put out another similar post, but let me ask this question another way in
> hopes of generating more feedback.
>
> I have an application with many forms that contain dynamic lists of
> elements. For example, rows of elements that contain a checkbox, select
> list, and 2 text boxes for each element.
>
> In traditional JSP design, normally I would create a loop and name these
> elements "rowbox1", "rowselect1", "rowtext1", "rowtext21", ...
> "rowbox(n)"...etc. At any rate, you get the idea; we've all done this.
>
> With struts, you have the mapped and indexed property syntax that works
> great for pre-populated forms. For example, I can have an "open" action that
> pre-populates an ActionForm with all the nested data and forward to a JSP
> that allows editing. Everything looks great.
>
> The PROBLEM is submitting this form. I haven't found a way to make Struts
> auto-allocate space in a collection (or a Map, for that matter) in an
> ActionForm for the submit action. Almost every example on this I've seen
> deals with a fixed number of elements, and most of these still focus on the
> pre-populate action. These examples completely avoid this issue.
>
> So, when the number of elements on the form VARIES, what is the "best
> practice" in design for this? I'm talking about an indexed or mapped
> collection that contains other Java Beans. How can you get these to submit
> properly into an ActionForm? If there are options, can you weigh the
> pros/cons of each?
>
> For example, I'm sure a session-scope bean would accomplish this, but I stay
> away from session-scope beans because of clustered deployment issues. I
> would imagine a hidden value giving the length might be useful, but I'm not
> sure where in the ActionForm's initialization sequence it could be used.
> Perhaps I need to do something different in the reset() method? Are there
> other options?
>
> Nate
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org