Controllers are where the actions in the Catalyst framework reside. Each action is represented by a function with an attribute to identify what kind of action it is. See the Catalyst::Dispatcher for more info about how Catalyst dispatches to actions.

This specifies the internal namespace the controller should be bound to. By default the controller is bound to the URI version of the controller name. For instance controller 'MyApp::Controller::Foo::Bar' will be bound to 'foo/bar'. The default Root controller is an example of setting namespace to '' (the null string).

Allows you to set the attributes that the dispatcher creates actions out of. This allows you to do 'rails style routes', or override some of the attribute definitions of actions composed from Roles. You can set arguments globally (for all actions of the controller) and specifically (for a single action).

In the case above every sub in the package would be made into a Chain endpoint with a URI the same as the sub name for each sub, chained to the sub named base. Ergo dispatch to /example would call the base method, then the example method.

Allows you to set constructor arguments on your actions. You can set arguments globally and specifically (as above). This is particularly useful when using ActionRoles (Catalyst::Controller::ActionRole) and custom ActionClasses.

Returns the private namespace for actions in this component. Defaults to a value from the controller name (for e.g. MyApp::Controller::Foo::Bar becomes "foo/bar") or can be overridden from the "namespace" config key.

Think of action attributes as a sort of way to record metadata about an action, similar to how annotations work in other languages you might have heard of. Generally Catalyst uses these to influence how the dispatcher sees your action and when it will run it in response to an incoming request. They can also be used for other things. Here's a summary, but you should refer to the linked manual page for additional help.

Matches the current action against the content-type of the request. Typically this is used when the request is a POST or PUT and you want to restrict the submitted content type. For example, you might have an HTML for that either returns classic url encoded form data, or JSON when Javascript is enabled. In this case you may wish to match either incoming type to one of two different actions, for properly processing.

Please keep in mind that when dispatching, Catalyst will match the first most relevant case, so if you use the Consumes attribute, you should place your most accurate matches early in the Chain, and your 'catchall' actions last.

Please note that this feature does not let you actually assign new functions to actions via subroutine attributes, but is really more for creating useful aliases to existing core and extended attributes, and transforms based on existing information (like from configuration). Code for actually doing something meaningful with the subroutine attributes will be located in the Catalyst::Action classes (or your subclasses), Catalyst::Dispatcher and in subclasses of Catalyst::DispatchType. Remember these methods only get called basically once when the application is starting, not per request!