controller_class

mode

my $mode = $app->mode;
$app = $app->mode('production');

The operating mode for your application, defaults to a value from the MOJO_MODE and PLACK_ENV environment variables or development. Right before calling startup, Mojolicious will pick up the current mode, name the log file after it and raise the log level from debug to info if it has a value other than development.

moniker

my $moniker = $app->moniker;
$app = $app->moniker('foo_bar');

Moniker of this application, often used as default filename for configuration files and the like, defaults to decamelizing the application class with "decamelize" in Mojo::Util.

secret

my $secret = $app->secret;
$app = $app->secret('passw0rd');

A secret passphrase used for signed cookies and the like, defaults to the moniker of this application, which is not very secure, so you should change it!!! As long as you are using the insecure default there will be debug messages in the log file reminding you to change your passphrase.

validator

Validate form data, defaults to a Mojolicious::Validator object. Note that this attribute is EXPERIMENTAL and might change without warning!

METHODS

Mojolicious inherits all methods from Mojo and implements the following new ones.

new

my $app = Mojolicious->new;

Construct a new Mojolicious application, calling ${mode}_mode and startup in the process. Will automatically detect your home directory and set up logging based on your current operating mode. Also sets up the renderer, static file server, a default set of plugins and an around_dispatch hook with the default exception handling.

These hooks are currently available and are emitted in the listed order:

after_build_tx

Emitted right after the transaction is built and before the HTTP request gets parsed.

$app->hook(after_build_tx => sub {
my ($tx, $app) = @_;
...
});

This is a very powerful hook and should not be used lightly, it makes some rather advanced features such as upload progress bars possible. Note that this hook will not work for embedded applications. (Passed the transaction and application object)

before_dispatch

Emitted right before the static file server and router start their work.

$app->hook(before_dispatch => sub {
my $c = shift;
...
});

Very useful for rewriting incoming requests and other preprocessing tasks. (Passed the default controller object)

after_static

Emitted after a static file response has been generated by the static file server.

Emitted after the static file server determined if a static file should be served and before the router starts its work.

$app->hook(before_routes => sub {
my $c = shift;
...
});

Mostly used for custom dispatchers and collecting metrics. (Passed the default controller object)

around_action

Emitted right before an action gets invoked and wraps around it, so you have to manually forward to the next hook if you want to continue the chain. Default action dispatching is the last hook in the chain, yours will run before it.

This is a very powerful hook and should not be used lightly, it allows you for example to pass additional arguments to actions or handle return values differently. (Passed a callback leading to the next hook, the current controller object, the action callback and a flag indicating if this action is an endpoint)

after_render

Emitted after content has been generated by the renderer that is not partial. Note that this hook can trigger out of order due to its dynamic nature, and with embedded applications will only work for the application that is rendering.

Mostly used for post-processing dynamically generated content. (Passed the current controller object, a reference to the content and the format)

after_dispatch

Emitted in reverse order after a response has been rendered. Note that this hook can trigger out of order due to its dynamic nature, and with embedded applications will only work for the application that is rendering.

$app->hook(after_dispatch => sub {
my $c = shift;
...
});

Useful for rewriting outgoing responses and other post-processing tasks. (Passed the current controller object)

around_dispatch

Emitted right before the before_dispatch hook and wraps around the whole dispatch process, so you have to manually forward to the next hook if you want to continue the chain. Default exception handling with "render_exception" in Mojolicious::Controller is the first hook in the chain and a call to dispatch the last, yours will be in between.

This is a very powerful hook and should not be used lightly, it allows you for example to customize application wide exception handling, consider it the sledgehammer in your toolbox. (Passed a callback leading to the next hook and the default controller object)