It's time to review the API, check how Moose can improve it, remove the redundancies and make it slim.
One more piece of food for thought: the thing that always bothered me is the first parameter every action receives:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sub index :Path :Args(0) { | |
my ($self, $c) = @_; |
I've never seen it used. I even was never sure if that thing is a controller object or if it is the controller class (i.e. if the actions are class or object methods), is it ever explained in the docs? Now I tested it and the output was:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
$VAR1 = bless( { | |
'_application' => 'DVDzbr', | |
'namespace' => '', | |
'action_namespace' => '', | |
'_controller_actions' => {} | |
}, 'DVDzbr::Controller::Root' ); |
so at least that action was an object method. I've reviewed the whole Catalyst Tutorial and, even though this parameter is passed to every action example there it is used in only a couple places (as
$self->action_for('list')
and $self->roles
). This does not seem like the best Huffman coding.
3 comments:
I use $self regularly. Usually, I end up having a controller base class, and sometimes I apply roles to controllers too.
The base class and/or roles will contain common operations like doing a fulltext search of some thing (the thing depending on controller), common authz operations, etc.
Think of the controller object as the thing responsible for handling the request, and the $c object as the request context itself.
What Catalyst gets wrong is that $c is both the request context and the application. The Catalyst devs know this is wrong, which is why the roadmap includes a plan for an application/context split, something I very much look forward to.
I did not say that we should get rid of that parameter - only that it is nearly never used nor explained in the docs. I am now convinced that context should be actually an attribute on that controller object - this way we could eliminate the other always passed on parameter, and I am sure people will find more usage for it once we start the discussions.
$self in actions is also used if you ever specify controller config; the controller is the object that will have it.
Post a Comment