ActionClass vs. Moose Role?

[Bill Moseley]

I was starting to implement a custom ActionClass (similar to RenderView) and then wondered if it would be better written as a Moose role.
Is there a reason to use one over another?

Last I looked, an action is limited to a single ActionClass (although it's easy to deal with that), but depending on how it's done, could apply multiple roles.

That is, one way would be to define the end() method in the role and not even have it in the consuming controller class, or another would be to have a end() stub
in the controller and and then use "before 'end'" in the role.  That way multiple roles could be applied.

Any guidance here?

Is everything going to be a role at some point? ;)

--
Bill Moseley
moseley@...

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Tomas Doran]

On 28 Aug 2009, at 18:25, Bill Moseley wrote:

> I was starting to implement a custom ActionClass (similar to  
> RenderView) and then wondered if it would be better written as a  
> Moose role.

Maybe - depends what you're doing. They're doing different things  
really, and I'd need more details to make a recommendation.

> Is there a reason to use one over another?
>
> Last I looked, an action is limited to a single ActionClass  
> (although it's easy to deal with that), but depending on how it's  
> done, could apply multiple roles.

Catalyst::Controller::ActionRole gets around this, you can apply many  
roles to your action.

> That is, one way would be to define the end() method in the role and  
> not even have it in the consuming controller class, or another would  
> be to have a end() stub
> in the controller and and then use "before 'end'" in the role.  That  
> way multiple roles could be applied.

Yep, that also totally works.

> Is everything going to be a role at some point? ;)

Not _everything_, but yes - a lot of stuff..

Cheers
t0m


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Bill Moseley]

On Fri, Aug 28, 2009 at 10:29 AM, Tomas Doran <bobtfish@...> wrote:

On 28 Aug 2009, at 18:25, Bill Moseley wrote:

I was starting to implement a custom ActionClass (similar to RenderView) and then wondered if it would be better written as a Moose role.

Maybe - depends what you're doing. They're doing different things really, and I'd need more details to make a recommendation.

Well, if you were going to write something like RenderView now would you still write it as an ActionClass?

The purpose is to have a standard end() that I use in multiple applications -- similar to RenderView as I mentioned.

I guess the difference is if you want to apply code to any action vs. a specific action.  RenderView is typically applied just to the end() method (or a method forwarded to from end() ), so maybe it's really better as a role since it would always alter end().

But if I want to apply code to different (and specific) actions then ActionClass is probably better since it can be set per action.

Anyway, using "before 'end'" is probably the way to go in the role instead of "sub end".

BTW -- will the helpers for catalyst.pl start generating Moose-ified context and controller classes at some point soon?

--
Bill Moseley
moseley@...

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Tomas Doran]

On 28 Aug 2009, at 19:05, Bill Moseley wrote:
> Well, if you were going to write something like RenderView now would  
> you still write it as an ActionClass?

Yes, as Render view isn't something I would ever want two of them on  
the same action.

As a counter example, Catalyst::ActionRole::ACL is _much better_ as an  
action role, as then it plays nicely with Catalyst::Action::REST  
(which should itself be an actionrole!) and other things..

> The purpose is to have a standard end() that I use in multiple  
> applications -- similar to RenderView as I mentioned.

Yeah, in your case, I would probably just go with a controller role  
which wraps the end method, as this is conceptually simpler than an  
actionclass, but either is a perfectly appropriate decision.

> Anyway, using "before 'end'" is probably the way to go in the role  
> instead of "sub end".

Yes, that's significantly better, due to the fact that methods from  
roles will be silently ignored if the local class has a method of that  
name.

What I'd be doing is something like this:

package MyApp::Role::Foo;
use Moose::Role -traits => 'MethodAttributes';

sub end : Action {}

before 'end' => sub { # Your code here };

package MyApp::Controller::Foo;
use Moose;
BEGIN { extends 'Catalyst::Controller' }
with 'MyApp::Role::Foo';

# Works like this, OR you can say:
# sub end : Action {
#     # Your code here, will get wrapped with your modifier.
# }

> BTW -- will the helpers for catalyst.pl start generating Moose-ified  
> context and controller classes at some point soon?

Yes, this is in the pipeline right now - but nobody has wanted to  
tackle it till the GSOC -Devel refactoring is complete. This is  
hopefully going to be brushed up and merged fairly soon now. :)

Cheers
t0m


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Aristotle Pagaltzis]

* Tomas Doran <bobtfish@...> [2009-09-02 16:30]:

>* Bill Moseley <moseley@...> [2009-08-28 20:10]:
>> I guess the difference is if you want to apply code to any
>> action vs. a specific action. RenderView is typically applied
>> just to the end() method (or a method forwarded to from end()
>> ), so maybe it's really better as a role since it would always
>> alter end().
>>
>> But if I want to apply code to different (and specific)
>> actions then ActionClass is probably better since it can be
>> set per action.
>>
>> Anyway, using "before 'end'" is probably the way to go in the
>> role instead of "sub end".
>
> Yes, that's significantly better, due to the fact that methods
> from roles will be silently ignored if the local class has
> a method of that name.
>
> What I'd be doing is something like this:
>
> package MyApp::Role::Foo;
> use Moose::Role -traits => 'MethodAttributes';
>
> sub end : Action {}
>
> before 'end' => sub { # Your code here };
>
> package MyApp::Controller::Foo;
> use Moose;
> BEGIN { extends 'Catalyst::Controller' }
> with 'MyApp::Role::Foo';
>
> # Works like this, OR you can say:
> # sub end : Action {
> #     # Your code here, will get wrapped with your modifier.
> # }

I seriously disagree. This essentially repurposes `sub end` to
perform the job of `after 'end'` and makes it non-obvious how to
run code before the mixed-in `before 'end'`. In contrast, if the
role simply does its work in `sub end`, then it is completely
clear what `before`/`after`/`around` in user will do.

> Yes, that's significantly better, due to the fact that methods
> from roles will be silently ignored if the local class has
> a method of that name.

No. Rather, it indicates to me that Ovid is not the only one who
should be banging his drum: role composition should just not
succeed silently in such cases. It should require an explicit
request of some form. To me, the semantic distortion you
suggested is an unconscious workaround that indicates that the
problem actually is one in practice and not only in theory.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/