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 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 {
> mapping.freeze(); // Just for good measure
> }
> }
>
>
> Quoting [EMAIL PROTECTED]:
>
>> 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 can
>> identify a Web Service request in processValidate() based on some
>> attributes
>> I set in processPreprocess().
>>
>> 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 protected.
>>
>> So, enter the hackery of the following class...
>>
>> package org.apache.struts.config;
>>
>> import org.apache.struts.action.ActionMapping;
>> public class ACUnfreezer {
>> public static void unfreeze(ActionMapping mapping) {
>> mapping.configured = false;
>> }
>> }
>>
>> So, in processValidate(), I simply do:
>>
>> if (request is a web service) [
>> ACUnfreezer.unfreeze(mapping);
>> mapping.setInput(the new JSP to go to in case of validation errors);
>> mapping.freeze(); // Just for good measure
>> }
>> return super.processValidate(request, response, form, mapping);
>>
>> So, regular requests work as before, and the Web Service requests will
>> be
>> redirected if validation errors occur. Beautiful!
>>
>> In an EXTREMELY hacky kind of way!
>>
>> Thanks for the talkback Paul and Joe, I'm not sure how long it would
>> have
>> taken on my own to get to this solution, if at all. Of course, I
>> suppose
>> that means you have to accept some of the blame for such a hack-job :)
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>>
>> 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.)
>> >
>> > There is nothing sacred about the original instances of ActionMapping
>> > which are created by processing the struts-config file. The wildcard
>> > mapping support results in dynamic construction of ActionMappings
>> > which have parameters replaced according to the wildcard match.
>> >
>> > You could either use your own ModuleConfig implementation with a
>> > custom implementation of findActionConfig(path) or, if the
>> > determination of the input depends on request data as well as the
>> > path, override processMapping in the RequestProcessor.
>> >
>> > I still think using the ComposableRequestProcessor is an easier
>> solution!
>> >
>> > Joe
>> >
>> >
>> > 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:[EMAIL PROTECTED]
>> >>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: [EMAIL PROTECTED]
>> >>For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >>
>> >>
>>
>>>------------------------------------------------------------------------------
>> >>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: [EMAIL PROTECTED]
>> >>For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> > --
>> > Joe Germuska
>> > [EMAIL PROTECTED]
>> > http://blog.germuska.com
>> > "Narrow minds are weapons made for mass destruction" -The Ex
>> >
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
