Hi Ted, others
What would you recommend generally in terms of how to handle the following
concept being incorporated into a web app. It relates to Debasish's
question to some extent.
Concept = Web app consists of management screens for each major
object/entity. Instead of the standard approach -:
==========================
- MANAGE X
- Show all X's
- Edit/Add/Delete X
- MANAGE Y
- Show all Y's
- Edit/Add/Delete Y
==========================
we want to take an approach which considers that there could be large
numbers of the items, so we want to be a SEACH PAGE which allows the results
to be scoped down. That is -:
==========================
- MANAGE X
- Search for Xs page
- Show resultant X's (scoped down)
- Edit/Add/Delete X
etc
==========================
The key concept point is that after an Edit/Add/Delete to an X one needs to
be returned to the "Show resultant X's" page (ie not show all Xs page).
How would you recommend handling this. Either -:
(a) Have session level X_Search_Form to hold search critera?
(b) Pass search critera right through the pages, as hidden parameters where
necessary?
One way I thought for the latter was to have a single FORM for X which
included the normal X attributes, PLUS the search attributes. It would be
this single struts action form which would be passed through the pages. Eg
X_Action_Form
* title
* description
* title_search_attribute
* description_search_attribute
Any comments.
Regards
Greg
----Original Message Follows----
From: Ted Husted <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Removing session scoped ActionForm beans
Date: Fri, 23 Nov 2001 18:52:51 -0500
The object create for an ActionForm is not going to be a difference that
makes a difference. Personally, I would be more concerned about un-used
ActionForm hanging around in the session, and sucking up resources, than
creating a new one for another batch. If for any reason they don't
choose another menu item, the object is going to live-on to the end of
their session.
As far as best practices go, my personal favorite is "early optimization
is the root of all evil" ;-)
Debasish Ghosh wrote:
>
> Hi -
>
> In our application, we have quite a few multi-page
> forms, where the ActionForm had to be created at the
> session scope. A typical example is an entry screen,
> where the user enters a record (spanning multiple
> pages) and presses "submit". The record gets inserted
> into the database and the form is cleared for the next
> entry. Typically a user will enter many records in one
> go once he is in the entry mode.
>
> In this case, does it make sense to remove these
> action forms from the session after each "submit" ?
>
> If I am not very mistaken, then Struts creates an
> ActionForm only when one does not exist in the
> specified scope with the same name. Hence I feel that
> we can gain here by not removing the action form from
> the session every time he does a "submit", since in
> that case Struts will re-create the form when it is
> loaded again.
>
> Then how do we do the necessary cleanup of the
> session-scoped ActionForm ? One option may be to do
> the cleanup when the user goes to some other menu item
> from the entry mode. I would like to know of any
> existing best practices in this case. Please help !!
>
> Best Regards.
>
> - Debasish
>
> __________________________________________________
> Do You Yahoo!?
> Listen to your Yahoo! Mail messages from any phone.
> http://phone.yahoo.com
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
