struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <ahardy.str...@cyberspaceroad.com>
Subject Re: Exception Handling keeping user input
Date Sat, 22 Dec 2007 23:58:49 GMT
OK, I'm with you on that point, but the interceptor should just return the user 
to the 'input' result in the event of an exception (and a redirect would lose 
the parameters). I thought it would require 'input' to be the default result if 
none other is specified.

Martin Gainty on 22/12/00 21:00, wrote:
> Hi Adam
> You can redirect to a customised Action e.g.
>        <result name="back" type="redirect">${redirectURL}</result>
> 
> OR
> you can call a predefined action with customised parameter
>         <result name="success"
> type="redirect-action">otherAction?id=${id}</result>
> 
> http://struts.apache.org/2.x/docs/parameters-in-configuration-results.html
> 
>>>From across the pond
> M--
> 
> ----- Original Message -----
> From: "Adam Hardy" <ahardy.struts@cyberspaceroad.com>
> To: "Struts Users Mailing List" <user@struts.apache.org>
> Sent: Saturday, December 22, 2007 2:32 PM
> 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.


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


Mime
View raw message