struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy JGR. Grumbach" <...@pulsar.be>
Subject RE: Exception Handling keeping user input
Date Wed, 26 Dec 2007 15:38:45 GMT
Hi Adam,

The chosen result is defined in your exception definition (in the struts
config file) - exactly like the default exception interceptor of struts,
nothing has changed about that. See
http://struts.apache.org/2.x/struts2-core/apidocs/com/opensymphony/xwork
2/interceptor/ExceptionMappingInterceptor.html

For example, in my case, it is a global exception: 

<global-exception-mappings>
	<exception-mapping exception="org.[...].myException"
result="input"/>
</global-exception-mappings>

Hope it helps,

Jeremy

-----Original Message-----
From: Adam Hardy [mailto:ahardy.struts@cyberspaceroad.com] 
Sent: Saturday, December 22, 2007 8:33 PM
To: Struts Users Mailing List
Subject: Re: Exception Handling keeping user input

Jeremy,
how do you control which result is chosen?

Adam

Jeremy JGR. Grumbach on 20/12/07 13:14, wrote:
> It's working with an interceptor :-)
> 
> All my actions are implementing ActionSupport and I use the
> ActionSupport class in my interceptor.
> 
> This is maybe not the final version, and every comments are welcome,
but
> it's working with this code. My goal is to catch only the exception of
> type MyException for the moment.
> 
> I have of course added my exception interceptor in the interceptors
> stack.
> 
> public class MyExceptionMappingInterceptor extends
> ExceptionMappingInterceptor {
> 
> protected void publishException(ActionInvocation actionInvocation,
> ExceptionHolder exceptionHolder) {
> 		super.publishException(actionInvocation,
> exceptionHolder);
> 
> 	     ActionContext invocationContext =
> actionInvocation.getInvocationContext();
> 
> 	     if (exceptionHolder.getException() instanceof MyException)
> {
> 	    	 MyException myException =
> (MyException)exceptionHolder.getException();
> 	    	 Object action = actionInvocation.getAction();
> 	    	 if (action instanceof ValidationAware) {
> 	    		 ValidationAware va = (ValidationAware) action;
> 	    		 String key = myException.getKey();
> 	    		 String message = "";
> 	    		 if (actionInvocation.getAction() instanceof
> ActionSupport) {
> 	    			 message =
> ((ActionSupport)actionInvocation.getAction()).getText(key);
> 	    		 } else {
> 	    			 message = key;
> 	    		 }
> 	    		 va.addActionError(message);
> 	    	 }
> 	     }
> 	}
> }
> 
> Best regards,
> 
> Jeremy
> 
> -----Original Message-----
> From: Jeremy JGR. Grumbach [mailto:JGR@pulsar.be] 
> Sent: Wednesday, December 19, 2007 10:28 AM
> To: Struts Users Mailing List
> Subject: RE: Exception Handling keeping user input
> 
> Yes I think it's more what I had in mind. My three requests were:
> 1) Go back to the "add" page without losing user input
> 2) Display an error message above the "add" form
> 3) Do this in a generic way => the business layer returns functional
> exceptions which appear automatically in the user screen
> 
> The points 1) and 2) are similar to the struts validation.
> 
> I'm already using Spring AOP to manage transaction, so I could add
some
> code to manage exceptions but first I will try with my own S2
Exception
> Interceptor.
> 
> I will post the results of my investigation here (and I hope I will
have
> something to post :))
> 
> Thanks!
> 
> Jeremy
> 
> -----Original Message-----
> From: Gary Affonso [mailto:glists2@greywether.com] 
> Sent: Wednesday, December 19, 2007 12:06 AM
> To: Struts Users Mailing List
> Subject: Re: Exception Handling keeping user input
> 
> Jeremy JGR. Grumbach wrote:
>> Thanks also for the answer,
>>
>> I'm using Velocity so no problem with the null values. 
>> And yes that's a way to manage exceptions, but I as said in my
> previous
>> post, I was looking for something more generic, without specific code
> in
>> all my actions.
> 
> If you want a generic exception handling solution I'd look at two
> things:
> 
> 1) AOP using Spring
> 2) The S2 Exception interceptor
> 
> Spring AOP can be configured to give advice to all your actions. 
> Basically the advice just catches exceptions and then returns a result

> code.  That keeps any exception handling code out of your action.  The

> advice can be as complex as you want it to be.  This is a bit 
> disadvantageous in that it's not S2 specific so you end up working 
> harder to do things like add error messages to the Action's error
maps.
> 
> The S2 Exception interceptor (and the exception configuration that
goes 
> along with it) give you an S2-specific way to implement a basically
the 
> same thing: a generic fault barrier at the action-layer.
> 
> It's documented here:
> 
>    http://struts.apache.org/2.0.11/docs/exception-configuration.html
> 
> If that specific interceptor doesn't do what you want, I suspect that
a 
> modestly customized version of its code will.
> 
> But none of that does what (I thought) you were originally asking
which 
> was to preserve the contents of the submitted form data
"automatically" 
> between a processing action and a view action.
> 
> Doing that in a generic fashion takes a little more work since the 
> form-data that needs to be preserved is different depending on the 
> view/process actions involved (sometimes the user is entering a
NewCar, 
> sometimes they're entering a NewCustomer).
> 
> I suppose you could come up with a generic interface (like 
> "SubmittedFormData") that would give your customized exception 
> interceptor something to work with.
> 
> For example:
> 
> In ProcessForm.action
> ---------------------
> 1) your custom exception interceptor catches any exceptions thrown
below
> 
> the action and that have propagated up to the action.  This is your 
> fault barrier.
> 
> 2) your custom exception interceptor looks for an object in the action

> that implements "SubmittedFormData".  If it finds it, it adds that 
> object to the session.
> 
> 3) your custom exception interceptor then does anything else
appropriate
> 
> (like add errors to the Action).
> 
> 4) your custom exception interceptor returns the result code of your 
> choice (probably INPUT in your case)
> 
> In ViewForm.action
> ------------------
> 1) You custom interceptor retrieves any "SubmittedFormData" object
from 
> the session and pushes it onto the stack.
> 
> 2) It then shows the view
> 
> And then in your view you can reference specific properties of the 
> SubmittedFormData object, regardles of what kind of object it actually

> is (NewCar, NewCustomer, etc).
> 
> The only thing that has to know the *actual* object type is your view 
> code that references real properties of the SubmittedFormData object. 
> Everything else (the interceptor, the session storage/retrieval code, 
> etc.) else just works with a "SubmittedFormData" object.
> 
> ----
> 
> I still feel like I'm missing something here.  Is the above more of
what
> 
> you had in mind?


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message