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:
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:
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