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
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
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
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
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
now makes perfect sense.
Also,
Joe's explanation is the right answer.
Thanks,
Paul
-Original Message-
From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 02, 2005 1:04 PM
To: Benedict, Paul C
Subject: RE: Extending RequestProcessor to handle
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
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 do
: 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 have your
ActionMappings
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
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 can
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
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 {
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
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 have your
ActionMappings dynamically instantiated with the correct value for
input
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
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
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: dev@struts.apache.org
Sent: Wednesday, February 02, 2005 7:57 PM
Subject: RE: Extending RequestProcessor
18 matches
Mail list logo
