purpose.
Dave Newton <[EMAIL PROTECTED]>
03/07/2007 02:20 PM
Please respond to
"Struts Users Mailing List"
To
Struts Users Mailing List
cc
Subject
Re: [OT] Re: Interceptor + putting information on the request
--- Matt Filion <[EMAIL PROTECTED]>
--- Matt Filion <[EMAIL PROTECTED]> wrote:
> Though the different situation seems like
"overkill".
I don't make my local vars 'final' either, but I know
enough people that do.
> How about expecting a programmer to look at the code
> becore they modify it? :)
Works great in theory ;)
But seriou
such purpose.
Dave Newton <[EMAIL PROTECTED]>
03/07/2007 02:01 PM
Please respond to
"Struts Users Mailing List"
To
Struts Users Mailing List
cc
Subject
Re: [OT] Re: Interceptor
--- Matt Filion <[EMAIL PROTECTED]> wrote:
> So for me it should be neither final or even a
member
> variable. Just a referance within the scope of the
> executed method.
>
> It creates an unatural relationship that could
> potential complicate the frameworks control of the
> ActionContext.
IIR
such purpose.
Dave Newton <[EMAIL PROTECTED]>
03/07/2007 01:15 PM
Please respond to
"Struts Users Mailing List"
To
Struts Users Mailing List
cc
Subject
[OT] Re: Interceptor + putti
Hi Matt,
Thanks very much, that fixed it.
-Nate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- Matt Filion <[EMAIL PROTECTED]> wrote:
> I really suggst you dont make the ActionContext
> final. Because the context changes for each request
> (its mutable) and making it final is a misleading
> statement.
Making local parameters that will not change 'final'
is a reasonably typical coding
I am actually doing something similar inside a couple of struts 2
applications I've written and I am able to populate the value stack and or
request just fine.
I do the following,
/*
* Interceptor
*/
public String intercept(ActionInvocation _invocation) thro
8 matches
Mail list logo
