Mailing List Archive: Catalyst: Users

ActionClass vs. Moose Role?

Index | Next | Previous | View Threaded

moseley at hank

Aug 28, 2009, 10:25 AM

Post #1 of 5 (1369 views)
Permalink

ActionClass vs. Moose Role?

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 [at] hank

bobtfish at bobtfish

Aug 28, 2009, 10:29 AM

Post #2 of 5 (1275 views)
Permalink

Re: ActionClass vs. Moose Role? [In reply to]

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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

moseley at hank

Aug 28, 2009, 11:05 AM

Post #3 of 5 (1280 views)
Permalink

Re: ActionClass vs. Moose Role? [In reply to]

On Fri, Aug 28, 2009 at 10:29 AM, Tomas Doran <bobtfish [at] 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 [at] hank

bobtfish at bobtfish

Aug 30, 2009, 10:16 AM

Post #4 of 5 (1236 views)
Permalink

Re: ActionClass vs. Moose Role? [In reply to]

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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

pagaltzis at gmx

Sep 5, 2009, 9:27 AM

Post #5 of 5 (1187 views)
Permalink

Re: ActionClass vs. Moose Role? [In reply to]

* Tomas Doran <bobtfish [at] bobtfish> [2009-09-02 16:30]:
>* Bill Moseley <moseley [at] hank> [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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads