Re: Exception Handling keeping user input

[Adam Hardy]

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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]