You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Miguel Almeida <mi...@almeida.at> on 2013/07/12 11:42:14 UTC
[Idea] Add ability for decorator pattern in Actions
I'd like to discuss with you an idea that came up a while ago while
trying to fulfil this need:
As a developer
I want to unit test annotations in my actions without having to run the
method's body
So that I can TDD more effectively and have quicker unit tests.
Namely, imagine an action:
@SecuredRoles("admin")
public String adminStuff(){
...
}
It would be interesting to have a way to test the @SecuredRoles without
having to run the method's body.
Upon discussion within the TDD group, a nice solution was suggested (in
italic. Skip below for my comments regarding Struts) :
So I would test and implement each aspect in isolation of the other -
the authorization would be implemented as a decorator (a-la GoF
decorator pattern) adding authorization to the underlaying (decorated)
MVC app. BTW I got to this technique by TDDing the separate aspects
(this is a good example of where the tests drive the design).
The technique to getting there is quite simple:
1. Extract an interface from your main class with all the public methods
2. Implement a decorator which adds authorization rules to a decorated
underlaying object. The decorator can implement the authorization rules
using your annotations (see this is where the academic meets the
practical - you'll in fact be reusing the already existing interceptor
but adapting it to a test-driven architecture)
3. in your tests, test the decorator providing a mock underlaying
decorated object, asserting in each test that given a request with a
user that has certain roles the underlaying method should or should not
be called.
The code might end up like this (semi-pseudo code but you get the idea)
Tests:
test_admin_can_call_method_a()
{
// setup a fake request with admin role:
httpRequest = buildRequestWithRole("admin");
// setup a mock app decorated with an authorzation decorator:
MockApp app = new MockApp();
AuthorizationDecorator authorizer = new AuthorizationDecorator(app);
// act - try calling method A in the decorator:
authorizer.MethodA(httpRequest);
// assert - underlaying method a should have been called:
Assert(app.MethodA.WasCalled==true);
}
test_regularUser_cannot_call_method_a()
{
// setup a fake request with regular user role:
httpRequest = buildRequestWithRole("regular user");
// setup a mock app decorated with an authorzation decorator:
MockApp app = new MockApp();
AuthorizationDecorator authorizer = new AuthorizationDecorator(app);
// act - try calling method A in the decorator:
authorizer.MethodA(httpRequest);
// assert - underlaying method a should not have been called:
Assert(app.MethodA.WasCalled==false);
}
In the SUT:
interface IApp
{
void MethodA()
void MethodB()
...
}
// this is the real app implementing methodA, methodB etc
class RealApp : IApp
{
void MethodA()
void MethodB()
...
}
// this is responsible for authorization
class AuthorizingDecorator : IApp
{
private IApp _decorated;
public AuthorizationDecorator(IApp decorated)
{
_decorated = decorated;
}
// each method is implemented using annotations
// and calling the underlaying decorated object
@SecuredRoles("admin, manager")
public void MethodA()
{
_decorated.MethodA();
}
@SecuredRoles("regular user")
public void MethodB()
{
_decorated.MethodB();
}
}
Then in your final MVC application you'd wire up the decorator with the
RealApp object:
IApp app = new AuthorizingDecorator(new RealApp());
This design is incompatible with Struts2 - if you decorate
DecoratedAction with OriginalAction, all Struts-related things (e.g.
ParamsInterceptor populating Action's fields from request, and I assume
every other interceptor's behaviour as well) will no work on
DecoratedAction, because it doesn't extend OriginalAction but rather
delegates to OriginalAction. E.g, a "someRequestParam" would be
populated OriginalAction if it was in the request, but it won't populate
originalAction.someRequestParam in DecoratedAction.
It would be very interesting to support the Decorator Pattern in Struts
actions. What are your thoughts on it?
Miguel Almeida
Re: [Idea] Add ability for decorator pattern in Actions
Posted by Christian Grobmeier <gr...@gmail.com>.
Also very neat.
As far as I know, struts is using a pre-1 version of Guice internally.
Upgrading it to a recent version is do-able, but costs a lot of time.
Also this might be a great challenge for the Struts Hackathon.
I also would like to point to http://onami.apache.org which might an
additional spice to the Struts-soup with Guice.
On Tue, Jul 16, 2013 at 10:18 PM, Ken McWilliams
<ke...@gmail.com> wrote:
> If we use Guice for DI we get its AOP features too? Not sure what Guice
> offers for AOP but a before method point cut should allow you to return
> what ever you want while preventing the method from actually doing
> anything. Trick would be how to expose that...
> http://code.google.com/p/google-guice/wiki/AOP
>
> Also once Guice is used I think the tags could stand for some DI, there are
> large daunting inheritance hierarchies within the struts2 tag
> implementations.
>
>
>
>
> On Tue, Jul 16, 2013 at 1:41 PM, Christian Grobmeier <gr...@gmail.com>wrote:
>
>> Oh yeah. I forgot about it. Great link, thanks.
>> Maybe a challenge for Struts 3 or the upcoming Struts Hackathon?
>>
>> On Tue, Jul 16, 2013 at 9:35 PM, Paul Benedict <pb...@apache.org>
>> wrote:
>> > If the decorator pattern is to supported in Struts, I vote it should be
>> > based on JEE 6 Interceptor.
>> > http://docs.oracle.com/javaee/6/tutorial/doc/gkeed.html
>> >
>> > Paul
>> >
>> >
>> > On Tue, Jul 16, 2013 at 2:30 PM, Christian Grobmeier <
>> grobmeier@gmail.com>wrote:
>> >
>> >> Hi,
>> >>
>> >> On Fri, Jul 12, 2013 at 11:42 AM, Miguel Almeida <mi...@almeida.at>
>> >> wrote:
>> >> > I'd like to discuss with you an idea that came up a while ago while
>> >> > trying to fulfil this need:
>> >> >
>> >> > As a developer
>> >> > I want to unit test annotations in my actions without having to run
>> the
>> >> > method's body
>> >> > So that I can TDD more effectively and have quicker unit tests.
>> >> >
>> >> > Namely, imagine an action:
>> >> >
>> >> > @SecuredRoles("admin")
>> >> > public String adminStuff(){
>> >> > ...
>> >> > }
>> >> >
>> >> > It would be interesting to have a way to test the @SecuredRoles
>> without
>> >> > having to run the method's body.
>> >> >...
>> >> > It would be very interesting to support the Decorator Pattern in
>> Struts
>> >> > actions. What are your thoughts on it?
>> >>
>> >> I am currently unsure if it would be so much benefit over the
>> >> interceptors we already have.
>> >> I mean, you can mock interceptors with actions, they are testable.
>> >> Maybe you can elaborate a bit more on that, because I think i missed
>> >> your key point.
>> >>
>> >> reading this message I was thinking if looking at AOP would make
>> >> sense. What are your feeling on
>> >> having an AOP plugin which supports some AOP framework?
>> >>
>> >> or what were your ideas for the implementation inside struts?
>> >>
>> >> Cheers
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> http://www.grobmeier.de
>> >> https://www.timeandbill.de
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Cheers,
>> > Paul
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Idea] Add ability for decorator pattern in Actions
Posted by Ken McWilliams <ke...@gmail.com>.
If we use Guice for DI we get its AOP features too? Not sure what Guice
offers for AOP but a before method point cut should allow you to return
what ever you want while preventing the method from actually doing
anything. Trick would be how to expose that...
http://code.google.com/p/google-guice/wiki/AOP
Also once Guice is used I think the tags could stand for some DI, there are
large daunting inheritance hierarchies within the struts2 tag
implementations.
On Tue, Jul 16, 2013 at 1:41 PM, Christian Grobmeier <gr...@gmail.com>wrote:
> Oh yeah. I forgot about it. Great link, thanks.
> Maybe a challenge for Struts 3 or the upcoming Struts Hackathon?
>
> On Tue, Jul 16, 2013 at 9:35 PM, Paul Benedict <pb...@apache.org>
> wrote:
> > If the decorator pattern is to supported in Struts, I vote it should be
> > based on JEE 6 Interceptor.
> > http://docs.oracle.com/javaee/6/tutorial/doc/gkeed.html
> >
> > Paul
> >
> >
> > On Tue, Jul 16, 2013 at 2:30 PM, Christian Grobmeier <
> grobmeier@gmail.com>wrote:
> >
> >> Hi,
> >>
> >> On Fri, Jul 12, 2013 at 11:42 AM, Miguel Almeida <mi...@almeida.at>
> >> wrote:
> >> > I'd like to discuss with you an idea that came up a while ago while
> >> > trying to fulfil this need:
> >> >
> >> > As a developer
> >> > I want to unit test annotations in my actions without having to run
> the
> >> > method's body
> >> > So that I can TDD more effectively and have quicker unit tests.
> >> >
> >> > Namely, imagine an action:
> >> >
> >> > @SecuredRoles("admin")
> >> > public String adminStuff(){
> >> > ...
> >> > }
> >> >
> >> > It would be interesting to have a way to test the @SecuredRoles
> without
> >> > having to run the method's body.
> >> >...
> >> > It would be very interesting to support the Decorator Pattern in
> Struts
> >> > actions. What are your thoughts on it?
> >>
> >> I am currently unsure if it would be so much benefit over the
> >> interceptors we already have.
> >> I mean, you can mock interceptors with actions, they are testable.
> >> Maybe you can elaborate a bit more on that, because I think i missed
> >> your key point.
> >>
> >> reading this message I was thinking if looking at AOP would make
> >> sense. What are your feeling on
> >> having an AOP plugin which supports some AOP framework?
> >>
> >> or what were your ideas for the implementation inside struts?
> >>
> >> Cheers
> >>
> >>
> >>
> >>
> >> --
> >> http://www.grobmeier.de
> >> https://www.timeandbill.de
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Paul
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [Idea] Add ability for decorator pattern in Actions
Posted by Christian Grobmeier <gr...@gmail.com>.
Oh yeah. I forgot about it. Great link, thanks.
Maybe a challenge for Struts 3 or the upcoming Struts Hackathon?
On Tue, Jul 16, 2013 at 9:35 PM, Paul Benedict <pb...@apache.org> wrote:
> If the decorator pattern is to supported in Struts, I vote it should be
> based on JEE 6 Interceptor.
> http://docs.oracle.com/javaee/6/tutorial/doc/gkeed.html
>
> Paul
>
>
> On Tue, Jul 16, 2013 at 2:30 PM, Christian Grobmeier <gr...@gmail.com>wrote:
>
>> Hi,
>>
>> On Fri, Jul 12, 2013 at 11:42 AM, Miguel Almeida <mi...@almeida.at>
>> wrote:
>> > I'd like to discuss with you an idea that came up a while ago while
>> > trying to fulfil this need:
>> >
>> > As a developer
>> > I want to unit test annotations in my actions without having to run the
>> > method's body
>> > So that I can TDD more effectively and have quicker unit tests.
>> >
>> > Namely, imagine an action:
>> >
>> > @SecuredRoles("admin")
>> > public String adminStuff(){
>> > ...
>> > }
>> >
>> > It would be interesting to have a way to test the @SecuredRoles without
>> > having to run the method's body.
>> >...
>> > It would be very interesting to support the Decorator Pattern in Struts
>> > actions. What are your thoughts on it?
>>
>> I am currently unsure if it would be so much benefit over the
>> interceptors we already have.
>> I mean, you can mock interceptors with actions, they are testable.
>> Maybe you can elaborate a bit more on that, because I think i missed
>> your key point.
>>
>> reading this message I was thinking if looking at AOP would make
>> sense. What are your feeling on
>> having an AOP plugin which supports some AOP framework?
>>
>> or what were your ideas for the implementation inside struts?
>>
>> Cheers
>>
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> --
> Cheers,
> Paul
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Idea] Add ability for decorator pattern in Actions
Posted by Paul Benedict <pb...@apache.org>.
If the decorator pattern is to supported in Struts, I vote it should be
based on JEE 6 Interceptor.
http://docs.oracle.com/javaee/6/tutorial/doc/gkeed.html
Paul
On Tue, Jul 16, 2013 at 2:30 PM, Christian Grobmeier <gr...@gmail.com>wrote:
> Hi,
>
> On Fri, Jul 12, 2013 at 11:42 AM, Miguel Almeida <mi...@almeida.at>
> wrote:
> > I'd like to discuss with you an idea that came up a while ago while
> > trying to fulfil this need:
> >
> > As a developer
> > I want to unit test annotations in my actions without having to run the
> > method's body
> > So that I can TDD more effectively and have quicker unit tests.
> >
> > Namely, imagine an action:
> >
> > @SecuredRoles("admin")
> > public String adminStuff(){
> > ...
> > }
> >
> > It would be interesting to have a way to test the @SecuredRoles without
> > having to run the method's body.
> >...
> > It would be very interesting to support the Decorator Pattern in Struts
> > actions. What are your thoughts on it?
>
> I am currently unsure if it would be so much benefit over the
> interceptors we already have.
> I mean, you can mock interceptors with actions, they are testable.
> Maybe you can elaborate a bit more on that, because I think i missed
> your key point.
>
> reading this message I was thinking if looking at AOP would make
> sense. What are your feeling on
> having an AOP plugin which supports some AOP framework?
>
> or what were your ideas for the implementation inside struts?
>
> Cheers
>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Cheers,
Paul
Re: [Idea] Add ability for decorator pattern in Actions
Posted by Christian Grobmeier <gr...@gmail.com>.
Hi,
On Fri, Jul 12, 2013 at 11:42 AM, Miguel Almeida <mi...@almeida.at> wrote:
> I'd like to discuss with you an idea that came up a while ago while
> trying to fulfil this need:
>
> As a developer
> I want to unit test annotations in my actions without having to run the
> method's body
> So that I can TDD more effectively and have quicker unit tests.
>
> Namely, imagine an action:
>
> @SecuredRoles("admin")
> public String adminStuff(){
> ...
> }
>
> It would be interesting to have a way to test the @SecuredRoles without
> having to run the method's body.
>...
> It would be very interesting to support the Decorator Pattern in Struts
> actions. What are your thoughts on it?
I am currently unsure if it would be so much benefit over the
interceptors we already have.
I mean, you can mock interceptors with actions, they are testable.
Maybe you can elaborate a bit more on that, because I think i missed
your key point.
reading this message I was thinking if looking at AOP would make
sense. What are your feeling on
having an AOP plugin which supports some AOP framework?
or what were your ideas for the implementation inside struts?
Cheers
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Idea] Add ability for decorator pattern in Actions
Posted by Miguel Almeida <mi...@almeida.at>.
Picking up on this, which got lost in my inbox...
On Tue, 2013-07-16 at 12:09 +0200, Lukasz Lenart wrote:
> 2013/7/12 Miguel Almeida <mi...@almeida.at>:
> > I'd like to discuss with you an idea that came up a while ago while
> > trying to fulfil this need:
> >
> > As a developer
> > I want to unit test annotations in my actions without having to run the
> > method's body
> > So that I can TDD more effectively and have quicker unit tests.
> >
> > Namely, imagine an action:
> >
> > @SecuredRoles("admin")
> > public String adminStuff(){
> > ...
> > }
> >
> > It would be interesting to have a way to test the @SecuredRoles without
> > having to run the method's body.
> >
> > Upon discussion within the TDD group, a nice solution was suggested (in
> > italic. Skip below for my comments regarding Struts) :
> >
> > So I would test and implement each aspect in isolation of the other -
> > the authorization would be implemented as a decorator (a-la GoF
> > decorator pattern) adding authorization to the underlaying (decorated)
> > MVC app. BTW I got to this technique by TDDing the separate aspects
> > (this is a good example of where the tests drive the design).
> >
> > The technique to getting there is quite simple:
> > 1. Extract an interface from your main class with all the public methods
> >
> > 2. Implement a decorator which adds authorization rules to a decorated
> > underlaying object. The decorator can implement the authorization rules
> > using your annotations (see this is where the academic meets the
> > practical - you'll in fact be reusing the already existing interceptor
> > but adapting it to a test-driven architecture)
> >
> > 3. in your tests, test the decorator providing a mock underlaying
> > decorated object, asserting in each test that given a request with a
> > user that has certain roles the underlaying method should or should not
> > be called.
> >
> > The code might end up like this (semi-pseudo code but you get the idea)
> >
> >
> > Tests:
> >
> > test_admin_can_call_method_a()
> > {
> > // setup a fake request with admin role:
> > httpRequest = buildRequestWithRole("admin");
> >
> > // setup a mock app decorated with an authorzation decorator:
> > MockApp app = new MockApp();
> > AuthorizationDecorator authorizer = new AuthorizationDecorator(app);
> >
> > // act - try calling method A in the decorator:
> > authorizer.MethodA(httpRequest);
> >
> > // assert - underlaying method a should have been called:
> > Assert(app.MethodA.WasCalled==true);
> > }
> >
> > test_regularUser_cannot_call_method_a()
> > {
> > // setup a fake request with regular user role:
> > httpRequest = buildRequestWithRole("regular user");
> >
> > // setup a mock app decorated with an authorzation decorator:
> > MockApp app = new MockApp();
> > AuthorizationDecorator authorizer = new AuthorizationDecorator(app);
> >
> > // act - try calling method A in the decorator:
> > authorizer.MethodA(httpRequest);
> >
> > // assert - underlaying method a should not have been called:
> > Assert(app.MethodA.WasCalled==false);
> > }
> >
> >
> >
> > In the SUT:
> >
> > interface IApp
> > {
> > void MethodA()
> > void MethodB()
> > ...
> > }
> >
> > // this is the real app implementing methodA, methodB etc
> > class RealApp : IApp
> > {
> > void MethodA()
> > void MethodB()
> > ...
> > }
> >
> > // this is responsible for authorization
> > class AuthorizingDecorator : IApp
> > {
> > private IApp _decorated;
> > public AuthorizationDecorator(IApp decorated)
> > {
> > _decorated = decorated;
> > }
> >
> > // each method is implemented using annotations
> > // and calling the underlaying decorated object
> > @SecuredRoles("admin, manager")
> > public void MethodA()
> > {
> > _decorated.MethodA();
> > }
> >
> >
> >
> > @SecuredRoles("regular user")
> > public void MethodB()
> > {
> > _decorated.MethodB();
> > }
> > }
> >
> > Then in your final MVC application you'd wire up the decorator with the
> > RealApp object:
> >
> > IApp app = new AuthorizingDecorator(new RealApp());
> >
> >
> >
> > This design is incompatible with Struts2 - if you decorate
> > DecoratedAction with OriginalAction, all Struts-related things (e.g.
> > ParamsInterceptor populating Action's fields from request, and I assume
> > every other interceptor's behaviour as well) will no work on
> > DecoratedAction, because it doesn't extend OriginalAction but rather
> > delegates to OriginalAction. E.g, a "someRequestParam" would be
> > populated OriginalAction if it was in the request, but it won't populate
> > originalAction.someRequestParam in DecoratedAction.
> >
> > It would be very interesting to support the Decorator Pattern in Struts
> > actions. What are your thoughts on it?
>
> Is it similar to ModelDriven?
>
> The problem I see is how to distinguish when to call decorator and
> when decorated object.
Similar to ModelDriven, in the sense that the model object is also
automatically populated in the action when it implements ModelDriven? If
so, then yes, I believe it's the same.
In terms of calls, calls to the decorated object would be made to build
the object, but in terms of actions, only what is made public in the
decorator would be available. I'm not sure I understand where problems
might arise, can you give an example?
Miguel
Re: [Idea] Add ability for decorator pattern in Actions
Posted by Lukasz Lenart <lu...@apache.org>.
2013/7/12 Miguel Almeida <mi...@almeida.at>:
> I'd like to discuss with you an idea that came up a while ago while
> trying to fulfil this need:
>
> As a developer
> I want to unit test annotations in my actions without having to run the
> method's body
> So that I can TDD more effectively and have quicker unit tests.
>
> Namely, imagine an action:
>
> @SecuredRoles("admin")
> public String adminStuff(){
> ...
> }
>
> It would be interesting to have a way to test the @SecuredRoles without
> having to run the method's body.
>
> Upon discussion within the TDD group, a nice solution was suggested (in
> italic. Skip below for my comments regarding Struts) :
>
> So I would test and implement each aspect in isolation of the other -
> the authorization would be implemented as a decorator (a-la GoF
> decorator pattern) adding authorization to the underlaying (decorated)
> MVC app. BTW I got to this technique by TDDing the separate aspects
> (this is a good example of where the tests drive the design).
>
> The technique to getting there is quite simple:
> 1. Extract an interface from your main class with all the public methods
>
> 2. Implement a decorator which adds authorization rules to a decorated
> underlaying object. The decorator can implement the authorization rules
> using your annotations (see this is where the academic meets the
> practical - you'll in fact be reusing the already existing interceptor
> but adapting it to a test-driven architecture)
>
> 3. in your tests, test the decorator providing a mock underlaying
> decorated object, asserting in each test that given a request with a
> user that has certain roles the underlaying method should or should not
> be called.
>
> The code might end up like this (semi-pseudo code but you get the idea)
>
>
> Tests:
>
> test_admin_can_call_method_a()
> {
> // setup a fake request with admin role:
> httpRequest = buildRequestWithRole("admin");
>
> // setup a mock app decorated with an authorzation decorator:
> MockApp app = new MockApp();
> AuthorizationDecorator authorizer = new AuthorizationDecorator(app);
>
> // act - try calling method A in the decorator:
> authorizer.MethodA(httpRequest);
>
> // assert - underlaying method a should have been called:
> Assert(app.MethodA.WasCalled==true);
> }
>
> test_regularUser_cannot_call_method_a()
> {
> // setup a fake request with regular user role:
> httpRequest = buildRequestWithRole("regular user");
>
> // setup a mock app decorated with an authorzation decorator:
> MockApp app = new MockApp();
> AuthorizationDecorator authorizer = new AuthorizationDecorator(app);
>
> // act - try calling method A in the decorator:
> authorizer.MethodA(httpRequest);
>
> // assert - underlaying method a should not have been called:
> Assert(app.MethodA.WasCalled==false);
> }
>
>
>
> In the SUT:
>
> interface IApp
> {
> void MethodA()
> void MethodB()
> ...
> }
>
> // this is the real app implementing methodA, methodB etc
> class RealApp : IApp
> {
> void MethodA()
> void MethodB()
> ...
> }
>
> // this is responsible for authorization
> class AuthorizingDecorator : IApp
> {
> private IApp _decorated;
> public AuthorizationDecorator(IApp decorated)
> {
> _decorated = decorated;
> }
>
> // each method is implemented using annotations
> // and calling the underlaying decorated object
> @SecuredRoles("admin, manager")
> public void MethodA()
> {
> _decorated.MethodA();
> }
>
>
>
> @SecuredRoles("regular user")
> public void MethodB()
> {
> _decorated.MethodB();
> }
> }
>
> Then in your final MVC application you'd wire up the decorator with the
> RealApp object:
>
> IApp app = new AuthorizingDecorator(new RealApp());
>
>
>
> This design is incompatible with Struts2 - if you decorate
> DecoratedAction with OriginalAction, all Struts-related things (e.g.
> ParamsInterceptor populating Action's fields from request, and I assume
> every other interceptor's behaviour as well) will no work on
> DecoratedAction, because it doesn't extend OriginalAction but rather
> delegates to OriginalAction. E.g, a "someRequestParam" would be
> populated OriginalAction if it was in the request, but it won't populate
> originalAction.someRequestParam in DecoratedAction.
>
> It would be very interesting to support the Decorator Pattern in Struts
> actions. What are your thoughts on it?
Is it similar to ModelDriven?
The problem I see is how to distinguish when to call decorator and
when decorated object.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org