You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Rick Reumann <st...@reumann.net> on 2004/08/13 23:37:20 UTC
clarification was: Re: Loosing request attributes
Craig McClanahan wrote:
>>>I can then
>>>call a private setUp() method in my Action that is used to set up my
>>>form with any other request attributes that should always be there.
>>
>>I'm curious why using the input parameter doesn't work for you?
>>
>
>
> Indeed ... the feature is working as it was designed, based on
> application user expectations that, if errors occur, whatever they
> typed in is redisplayed (even if it is wrong) so that it can be
> corrected. That's the way that any rich GUI client works, and nobody
> wants to use apps that force you to fill an entire form in again
> simply because you made one mistake.
I'm sorry I should have qualified.... I didn't mean setUp "my form" but
set up things "on the resulting JSP that I forward to" - for example
drop down lists etc. I never repopulate the form inputs and ActionForm
fields.. those stay populated fine... but Leandro's original question
was about objects that he was sticking in request scope with
request.setAttribute( ..) (not ActionForm properties). My point was that
those Request objects that a JSP might always need to have populated on
the page will be lost if you do form validation the conventional struts
way. Using Session or Application scope is not always the best place to
place Objects that a JSP might need, so when validation fails you need a
way to sometimes replace these objects - hence I call validate()
manually and use a setUp() method used to populate the Request with
objects my resulting JSP should have.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: clarification was: Re: Loosing request attributes
Posted by Craig McClanahan <cr...@gmail.com>.
On Fri, 13 Aug 2004 20:29:53 -0400, Rick Reumann <st...@reumann.net> wrote:
>
> I notice this problem ( validation fails now lost select list on page )
> comes up a lot on this mailing list. Probably time I updated a wiki
> somewhere of the various approaches you can take to accomodate this
> problem ( application scope, session scope, persistence layer caching,
> call validate manually, combination of the above, etc).
>
Updating the Wiki would be awesome!
> --
> Rick
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: clarification was: Re: Loosing request attributes
Posted by Rick Reumann <st...@reumann.net>.
Craig McClanahan wrote:
> That makes more sense now.
>
> I tend to put all my lookup data (for dropdown lists and such) into
> application scope (if its global) or session scope (if it's user
> specific), primarily as a performance enhancement ... I only have to
> look it up once, instead of once per request. As a side effect, you
> don't have to worry about the values going away, like you do if they
> are in request scope.
I try to do that also, but often times the lists you need to display are
specific to the type of user logged in. In these cases, if I don't
manually validate and then use the setUp() method to repopulate some
Request scope stuff, I'll usually just stick the Lists in Session scope.
If memory performance is a super major concern then I stick to the
manual validate in the Action and repopulate the request as needed with
the Lists it needs.
I notice this problem ( validation fails now lost select list on page )
comes up a lot on this mailing list. Probably time I updated a wiki
somewhere of the various approaches you can take to accomodate this
problem ( application scope, session scope, persistence layer caching,
call validate manually, combination of the above, etc).
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: clarification was: Re: Loosing request attributes
Posted by Craig McClanahan <cr...@gmail.com>.
On Fri, 13 Aug 2004 17:37:20 -0400, Rick Reumann <st...@reumann.net> wrote:
> Craig McClanahan wrote:
>
> >>>I can then
> >>>call a private setUp() method in my Action that is used to set up my
> >>>form with any other request attributes that should always be there.
> >>
> >>I'm curious why using the input parameter doesn't work for you?
> >>
> >
> >
> > Indeed ... the feature is working as it was designed, based on
> > application user expectations that, if errors occur, whatever they
> > typed in is redisplayed (even if it is wrong) so that it can be
> > corrected. That's the way that any rich GUI client works, and nobody
> > wants to use apps that force you to fill an entire form in again
> > simply because you made one mistake.
>
> I'm sorry I should have qualified.... I didn't mean setUp "my form" but
> set up things "on the resulting JSP that I forward to" - for example
> drop down lists etc. I never repopulate the form inputs and ActionForm
> fields.. those stay populated fine... but Leandro's original question
> was about objects that he was sticking in request scope with
> request.setAttribute( ..) (not ActionForm properties). My point was that
> those Request objects that a JSP might always need to have populated on
> the page will be lost if you do form validation the conventional struts
> way. Using Session or Application scope is not always the best place to
> place Objects that a JSP might need, so when validation fails you need a
> way to sometimes replace these objects - hence I call validate()
> manually and use a setUp() method used to populate the Request with
> objects my resulting JSP should have.
>
That makes more sense now.
I tend to put all my lookup data (for dropdown lists and such) into
application scope (if its global) or session scope (if it's user
specific), primarily as a performance enhancement ... I only have to
look it up once, instead of once per request. As a side effect, you
don't have to worry about the values going away, like you do if they
are in request scope.
> --
> Rick
Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org