Changing settings after binding in Struts 2

Question

I have an action that receives some parameters from the user (e.g. date). This action creates many different reports, so it has many different methods. I need to configure these parameters (set the time before midnight) before each method. The prepare method is executed before the parameters are bound. Is there any other interceptor or any other agreement that allows me to do this?

Answer 1

Use <interceptor-ref name="paramsPrepareParamsStack"/>

 <!-- An example of the params-prepare-params trick. This stack is exactly the same as the defaultStack, except that it includes one extra interceptor before the prepare interceptor: the params interceptor. This is useful for when you wish to apply parameters directly to an object that you wish to load externally (such as a DAO or database or service layer), but can't load that object until at least the ID parameter has been loaded. By loading the parameters twice, you can retrieve the object in the prepare() method, allowing the second params interceptor to apply the values on the object. --> 

If you use the Convention plugin, apply it to the action

 @Action(value="action1", interceptorRefs=@InterceptorRef ("paramsPrepareParamsStack")) 

Answer 2

Another way to go (cheap if you are coding now, expensive if you have already encoded everything) would be modular for every action you have to perform in one Struts2 action.

Then you will have something like BaseReportAction containing all the common attributes and methods shared using protected instead of private , by configuring the parameters and general operations in the execute() method;

And one action for each report that extends BaseReportAction, say

ExcelReportAction, PdfReportAction, etc.

or

MinimalReportAction, CompleteReportAction, etc.

and

DailyReportAction, MonthlyReportAction, etc.

And the only requirement would be to use super.execute(); as the first statement for each child action execute() method.

That way, you can take advantage of inheritance, have a lot smaller, cleaner (ultimately packaged in several subpackages). Actions instead of one huge action with many methods.

All utility methods used by several reports will be available only for these reports, and not for all others (say, for example, PDF and XLS files) ...

You can also use XML Validation for different actions (perhaps one report requires different inputs from another).

Finally, your setup code will be Thread-Safe (actions are thread safe, interceptors do not).

But as said, this is the choice of implementation that is better suited for the pre-code phase (even if it’s not so difficult to reorganize, depending on the size of the web application ...).