Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <31834937.1107368894499.JavaMail.root@chiron.lunarpages.com>
Date: Wed, 2 Feb 2005 10:28:14 -0800 (PST)
From: fzlists@omnytex.com
To: dev@struts.apache.org
Subject: RE: Extending RequestProcessor to handle validation errors
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_Part_16_11376629.1107368894446"

------=_Part_16_11376629.1107368894446
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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 the validation.)

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 simply call setInput() on the mapping with the new value, and everything should work as expected.

Sound about right to you Joe?
 
> I still think using the ComposableRequestProcessor is an easier solution!

You didn't answer the question I was hoping you would though :)  Is that class based on the CoR-based Struts codebase?  If so, while I in no way diagree with you that it's probably the better/easier solution, I'm not quite ready to move to the CoR paradigm with this yet.
 
> Joe

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

> At 12:46 PM -0500 2/2/05, Benedict, Paul C wrote:
>>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 input and success forward.
>>
>>Is your question actually posed by a misdesign?
>>
>>Thanks,
>>Paul
>>
>>-----Original Message-----
>>From: Frank W. Zammetti (MLists) [mailto:fzlists@omnytex.com]
>>Sent: Wednesday, February 02, 2005 12:39 PM
>>To: dev@struts.apache.org
>>Subject: Extending RequestProcessor to handle validation errors
>>
>>
>>Hi folks... I'm working on an update of my Struts Web Services project,
>>and I can't seem to work out how to do something...
>>
>>What I want to do is have a way to redirect to a given JSP when
>> ActionForm
>>validation errors occur that will OVERRIDE whatever might be configured
>> in
>>the action mapping.  In other words... in a normal application,
>> validation
>>errors occur and we get forwarded back to the input page.  I want to be
>>able to redirect to a different JSP, REGARDLESS of what the input page
>> is.
>>
>>I looked at overriding the processValidate() method of RequestProcessor,
>>but I don't see how that can work... Looking at the source of the
>> original
>>RP (v1.1 this all is) I see that it does the forward and then returns a
>>boolean, true if no errors occur or false otherwise, so it doesn't look
>>like I have the opportunity to do something like the following
>>psuedo-code:
>>
>>myOverriden_ProcessValidate() {
>>
>>   boolean b = super.processValidate();
>>   if (!b) {
>>     forward to my jsp
>>   }
>>
>>}
>>
>>... because by the time I hit my check of b, the forward or redirect has
>>already been done.  Is it possible to override the forward or redirect
>>that the super.processValidate() could do?  I didn't think so.  Am I
>>missing the obvious somewhere on how to do this, or maybe I'm barking up
>>the wrong tree to begin with?  Thanks all!
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>>------------------------------------------------------------------------------
>>Notice:  This e-mail message, together with any attachments,
>>contains information of Merck & Co., Inc. (One Merck Drive,
>>Whitehouse Station, New Jersey, USA 08889), and/or its affiliates
>>(which may be known outside the United States as Merck Frosst, Merck
>>Sharp & Dohme or MSD and in Japan, as Banyu) that may be
>>confidential, proprietary copyrighted and/or legally privileged. It
>>is intended solely for the use of the individual or entity named on
>>this message.  If you are not the intended recipient, and have
>>received this message in error, please notify us immediately by
>>reply e-mail and then delete it from your system.
>>------------------------------------------------------------------------------
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
> 
> 
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex
> 


------=_Part_16_11376629.1107368894446
Content-Type: text/plain; charset=us-ascii

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
------=_Part_16_11376629.1107368894446--