Friday, August 07, 2009

The Catalyst API

Now, after the Moose port is completed, it looks like a good time for reviewing the Catalyst API. It's not a secret that in my opinion some of the Catalyst practice is a cargo cult (for example using forward instead of a subroutine call), other parts could be greatly simplified. In How I Use Catalyst the interesting part is how Dave also does not use some important parts of the Catalyst API, and Marcus in his reply, even though he disagrees with Dave, still he does agree that there might be a more suitable API for some things.

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.


Anonymous said...

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.

zby said...

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.

hobbs said...

$self in actions is also used if you ever specify controller config; the controller is the object that will have it.