/ 
Kelp-2.21
River stage two • 22 direct dependents • 23 total dependents
/ Kelp::Manual::Controllers

NAME

Kelp::Manual::Controllers - Making your app use controllers

DESCRIPTION

This document describes the technical aspect of implementing controllers in your app. By default, Kelp application has no controllers - it resolves all your routes in the context of the main app. In other words, all routes take a instance of the web application as a first parameter - even if those routes live in another class.

Controllers lets you separate some of the route handling logic to other classes and have your subs take the object of the correct class as the first argument.

PSA: Modern controllers

New Kelp versions are very flexible when it comes to tweaking the call process of a route. However, the core of the framework uses legacy "reblessing" system of controllers for backward-compatibility reasons.

For all new projects which need controllers, you should configure your app to use KelpX::Controller. This extension implements a separate controller class hierarchy, much more fitting for a modern web development. It is an official extension supported by Kelp developers.

Refer to KelpX::Controller documentation for details on setting that up. The rest of this document contains only details about the legacy system, so it can be safely ignored if you choose to use that extension.

Legacy controller details

Core Kelp uses reblessing as a method of implementing controllers. There is no special base class for controllers - all controllers must be subclasses of Kelp.

Reblessing will happen after request is matched to a route. Route handler has to be specified as class and method string, and class must be a subclass of class configured for "base" in Kelp::Routes. "rebless" in Kelp::Routes must also be enabled for that to occur.

The default value of base field is the application class, so your application class is by default your main controller class. All other controllers must (directly or indirectly) inherit from your application class.

These methods will be automatically run on your controller object for each request:

  • route handler method

  • hooks (if available)

No other methods will be called from your controller unless you call them explicitly yourself. Application will be reblessed into a given controller only once per request. If a bridge route exists which uses the same controller as the regular route, the regular route will reuse the controller reblessed for the bridge. After the request ends, the reblessed controllers will be cleared.

Configuring controllers

Step 1: Configure the controller

It is a good practice to set up a different base, so that you separate general app code from request-handling code.

# config.pl
{
    modules_init => {
        Routes => {
            rebless => 1, # the app instance will be reblessed
            base => 'MyApp::Controller',
        }
    }
}

Step 2: Create a main controller class

This step is only required if you've changed the base.

# lib/MyApp/Controller.pm
package MyApp::Controller;
use Kelp::Base 'MyApp';

# Now $self is an instance of 'MyApp::Controller';
sub service_method {
    my $self = shift;
    ...;
}

1;

Step 3: Create any number of controller classes

They all must inherit from your main controller class.

# lib/MyApp/Controller/Users.pm
package MyApp::Controller::Users;
use Kelp::Base 'MyApp::Controller';

# Now $self is an instance of 'MyApp::Controller::Users'
sub authenticate {
    my $self = shift;
    ...;
}

1;

Step 4: Add routes with shorter class names

You no longer have to prefix destinations with the base controller class name.

# lib/MyApp.pm

...

sub build {
    my $self = shift;

    # if 'base' was not changed, this would have to be written as:
    # => 'Controller::Users::authenticate'
    $self->add_route('/login' => 'Users::authenticate');

}

CAVEATS

There are some controller gotchas which come from a fact that they are not by default constructed like a regular object:

Main application object is shallow-cloned before rebless

By default, controllers are only temporary. Setting top-level attributes in a controller, for example "charset" in Kelp, will work until the request is fully handled. After that, the controller copy will be destroyed and the changes will not propagate back to main application. Moreover, any extra fields you set in the controller will be lost when the request handling is over.

If your main app has no changing state, a special configuration field persistent_controllers can be added to combat this. If it is set to a true value, the app will be reblessed just once per controller. This means no changes to the main app attributes will be visible in controllers, but the controller will be free to set and use all of its attributes at will. This way your controllers will be reused indefinetly and no changes in app's state will propagade to controllers.

Note that by default, Kelp main class has no top-level state which may change between requests so it should be pretty safe to enable this configuration as long as you don't instantiate your controllers before app building is finished.

Getting a controller copy in build

Controllers are never actually constructed, but instead the main app object is cloned and reblessed into the correct class. Don't expect your override of new or build to ever be called. No automatic controller initialization happens in Kelp.

If you'd like to access a controller in other context than route handling - for example in build method, allowing you to move route definitions to the controller - you may use context tracking object:

# in MyApp.pm
sub build {
    my $self = shift;

    # get a temporary rebless of the app and call its bulid method
    # will return MyApp::Controller::Special, if route base is MyApp::Controller
    my $controller_special = $self->context->controller('Special');
    $controller_special->build;

    # will return the main controller (MyApp::Controller)
    my $controller = $self->context->controller;
    $controller->build;
}

Note that you will still have to use the controller name in routes even though they live in the same class:

# in MyApp/Controller/Special.pm
sub build {
    my $self = shift;

    # need to add special, even though this is controller special
    $self->add_route('/my_route' => 'special#handler');
}

sub handler { ... }

NOTE: Take extra care not to call build again if it wasn't overridden in a controller, as the controller will try to re-initialize the app, which will surely result in a loop! In addition, make sure to never call $self->SUPER::build in a controller.

A little trick to make sure your build don't get called more than once is to start it with a guard:

sub build {
    my $self = shift;
    return unless ref $self eq __PACKAGE__;
}

This way you don't have to worry about possibility of duplicated build calls as a result of inheritance.

Getting a main application object in a controller

This may be done by similarly using context:

sub handler {
    my $controller = shift;

    # this will always be the main app object
    my $app = $controller->context->app;
}

SEE ALSO

Kelp::Manual

SUPPORT