[S2]: When do I need to extend "ActionSupport"?

["Zheng, Xiahong" <Xi...@FMR.COM>]

Struts 2 promotes POJO based action. However I found most of the Action
classes from the sample application extends ActionSupport? By looking at
the ActionSupport class in Xwork, I found it implements quite a few
interfaces, e.g. Valicateable, ValidationAware, TextProvider,
LocalProvider and Action. My question is if I don't extend
ActionSupport, do I lose all the above functionalities, validation,
locale, etc, even if I have the corresponding interceptors configured?

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

Re: [S2]: When do I need to extend "ActionSupport"?

[Wes Wannemacher <we...@wantii.com>]

On Mon, 2008-04-14 at 12:49 -0700, Dave Newton wrote:
> --- "Zheng, Xiahong" <Xi...@FMR.COM> wrote:
> > Struts 2 promotes POJO based action. However I found most of the Action
> > classes from the sample application extends ActionSupport? By looking at
> > the ActionSupport class in Xwork, I found it implements quite a few
> > interfaces, e.g. Valicateable, ValidationAware, TextProvider,
> > LocalProvider and Action. My question is if I don't extend
> > ActionSupport, do I lose all the above functionalities, validation,
> > locale, etc, even if I have the corresponding interceptors configured?
> 
> Yes (more or less; some annotations may provide functionality without
> explicit interface implementation).
> 
> The interceptors (and other functions that expect the interfaces, like I18N)
> use the interfaces as markers to indicate that a various action should be
> performed, identify the existence of functionality, and so on.
> 
> Dave
> 

I will add to what Dave says, and ask why you wouldn't want to extend
ActionSupport? Although extending ActionSupport may seem like you are
tying yourself to the framework, I have never had a problem because the
functionality that ActionSupport adds is only loosely coupled to the
framework. Perhaps a better way to say it is that I've never had to
create mock objects to unit test an action that extends ActionSupport.
So, a MyAction action = new MyAction(); String res = action.execute();
Will work in JUnit w/o any special housekeeping (except calling
appropriate setters). If you still aren't convinced, then wrap your
POJOs with a thin class that implements ActionSupport i.e. -

public class MyAction extends ActionSupport {

    private MyPOJO pojo;
    public MyPOJO getPojo() {
        return pojo;
    }
    public void setPojo( MyPOJO pojo) {
        this.pojo = pojo;
    }
}

Then you can name your form fields like - 
<s:textfield name="pojo.memberVar" />

This way your POJOs are completely de-coupled from the framework. And,
to make things easier, you can implement ModelDriven which will allow
you to deal with your POJO directly within your form widgets. I would
add a code example, but it is all well-documented in the online docs.

-Wes 


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

Re: [S2]: When do I need to extend "ActionSupport"?

[Dave Newton <ne...@yahoo.com>]

--- "Zheng, Xiahong" <Xi...@FMR.COM> wrote:
> Struts 2 promotes POJO based action. However I found most of the Action
> classes from the sample application extends ActionSupport? By looking at
> the ActionSupport class in Xwork, I found it implements quite a few
> interfaces, e.g. Valicateable, ValidationAware, TextProvider,
> LocalProvider and Action. My question is if I don't extend
> ActionSupport, do I lose all the above functionalities, validation,
> locale, etc, even if I have the corresponding interceptors configured?

Yes (more or less; some annotations may provide functionality without
explicit interface implementation).

The interceptors (and other functions that expect the interfaces, like I18N)
use the interfaces as markers to indicate that a various action should be
performed, identify the existence of functionality, and so on.

Dave


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