Hi Kishore,
I've actually decided to not use this "trick" anyway, based on a point
raised by Niall. I'll actually be cloning the ActionMapping and
changing the input in that clone. I hope to actually implement this
today, but I have a huge conference call most of the day, so we'll see.
This m
> if (request is a web service) [
> ACUnfreezer.unfreeze(mapping);
> mapping.setInput(the new JSP to go to in case of validation errors);
This might fail in the case where the Controller's 'inputForward' is
set to true.
I have couple of questions regarding the "jsp" that you want to go to
incas
If it was me I would just create my own custom ActionMapping and have a
constructor which takes an ActionConfig and clones all its properties.
Niall
- Original Message -
From: <[EMAIL PROTECTED]>
To:
Sent: Wednesday, February 02, 2005 7:57 PM
Subject: RE: Extending RequestProc
That makes sense, cloning as Niall does sound right (shucks, had it working and
done!).
Simple question: how should the mapping be cloned? I mean, clearly when I
override processMapping() I'll just call the super version and then clone what
I recieve and return that, but how should I literally
I would recommend against unfreezing the ActionMappings; they are
shared throughout the application, and you have no way of knowing
whether some non-webservice request may come along in a minute and
get the same ActionMapping instance and get stuck with an incorrect
value for the "input" proper
t: Wednesday, February 02, 2005 6:28 PM
> Subject: RE: Extending RequestProcessor to handle validation errors
>
>
>> On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
>> > This actually stimulated another thought. Perhaps instead of
>> > overriding process validate, you c
Excellent point! It's done.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Wed, February 2, 2005 2:23 pm, [EMAIL PROTECTED] said:
> i might put that freeze in a finally block, if you're gonna do something
> nasty,
> better make sure you
i might put that freeze in a finally block, if you're gonna do something nasty,
better make sure you leave no footprints. :)
if (request is a web service) {
try {
ACUnfreezer.unfreeze(mapping);
mapping.setInput(the new JSP to go to in case of validation errors);
} finally {
mappin
GOT IT!
But, this might be the worst piece of hackery I've ever done. Check it out...
Joe's last response spurred me to realize that if I could override the input
field of the ActionMapping, I could do what I want. As I thought,
processPreprocess() fires before processValidate(), which means
On Wed, February 2, 2005 1:28 pm, [EMAIL PROTECTED] said:
> Actually, now you've stimulated a though in me! :)
>
> Correct me if I'm wrong, but processPreprocess() fires BEFORE
> processValidate(), correct? In that case, since I can in fact determine
> the input after processPreprocess() fires, I
> The problem as I discovered is that I can't just call setInput() in
> processValidate() because the configuration is frozen at that point. And,
> since the RequestProcessor isn't in the same package as ActionConfig (where >
> setInput() is found), I couldn't call setInput() since it's protect
At 10:28 AM -0800 2/2/05, [EMAIL PROTECTED] wrote:
On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
This actually stimulated another thought. Perhaps instead of
overriding process validate, you could arrange to have your
ActionMappings dynamically instantiated with the correct value for
"i
nt: Wednesday, February 02, 2005 6:28 PM
Subject: RE: Extending RequestProcessor to handle validation errors
> On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
> > This actually stimulated another thought. Perhaps instead of
> > overriding process validate, you could arrange to
On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
> This actually stimulated another thought. Perhaps instead of
> overriding process validate, you could arrange to have your
> ActionMappings dynamically instantiated with the correct value for
> "input" (assuming that you can know it before you
This actually stimulated another thought. Perhaps instead of
overriding process validate, you could arrange to have your
ActionMappings dynamically instantiated with the correct value for
"input" (assuming that you can know it before you do the validation.)
There is nothing sacred about the or
dict, Paul C
> Subject: RE: Extending RequestProcessor to handle validation errors
>
>
> Are you familiar with my project Paul? If not, I'll briefly explain
> (otherwise, just skip to the third paragraph)...
>
> It is a project that allows Actions to be exposed as Web Se
You are referring to the CoR-based Struts build, correct Joe? If not, I'm not
seeing that class in the 1.1 javadocs.
If your talking CoR as I think you are though, I haven't gotten that far yet :)
I'm trying to get this to a point of equillibrium that I'm happy with based on
the current codeb
Are you familiar with my project Paul? If not, I'll briefly explain
(otherwise, just skip to the third paragraph)...
It is a project that allows Actions to be exposed as Web Services with no
changes to the existing code. All a developer has to do is add a plug-in, and
optionally a new webserv
With the ComposableRequestProcessor, the validation is independent
from the command which puts an ActionForward into the context in the
event of a failed form validation. It should be very straightforward
for you to change the "SelectInput" command or add another one which
uses request context
Frank,
I am not sure of why you need this solution. I never came across your need
-- and perhaps because I never encountered the problem.
I can't imagine why you would want to dynamically control the input page.
For instance, I use MappingDispatchAction and each action entry has its own
specified
20 matches
Mail list logo
