view release on metacpan or  search on metacpan

lib/Kelp/Manual/Cookbook.pod  view on Meta::CPAN

        state $handle;
        if (!defined $handle || $reconnect) {
            my @config = @{ $self->config('dbi') };
            $handle = DBI->connect(@config);
        }

        return $handle;
    }

    # Use $self->dbh from here on ...

Same methods can be used for accessing the schema of L<DBIx::Class>.

=head2 Custom error pages

=head3 Error templates

The easiest way to set up custom error pages is to create templates in
I<views/error/> with the code of the error. For example: I<views/error/404.tt> and
I<views/error/500.tt>. You can render those manually using C<< $self->res->render_404 >>
and C<< $self->res->render_500 >>. To render another error code, you can use
C<< $self->res->render_error >>.

=head3 Within the route

For one-off rendering of errors, you can alternatively set the response headers
and content within the route:

    sub some_route {
        my $self = shift;
        $self->res->set_code(404)->template('my_404_template');
    }

=head2 Altering the behavior of a Kelp class method

The easiest solution would be to use L<KelpX::Hooks> module available on CPAN:

    use KelpX::Hooks;
    use parent "Kelp";

    # Change how template rendering function is called
    hook "template" => sub {
        my ($orig, $self, @args) = @_;

        # $args[0] is template name
        # $args[1] is a list of template variables
        $args[1] = {
            (defined $args[1] ? %{$args[1]} : ()),
            "my_var" => $self->do_something,
        };

        # call the original $self->template again
        # with modified arguments
        return $self->$orig(@args);
    };

=head2 Handling websocket connections

Since Kelp is a Plack-based project, its support for websockets is very
limited. First of all, you would need a Plack server with support for the psgi
I<streaming>, I<io> and I<nonblocking>, like L<Twiggy>. Then, you could
integrate Kelp application with a websocket application via
L<Kelp::Module::Websocket::AnyEvent> CPAN module (if the server implementation
is compatible with L<AnyEvent>):

    sub build {
        my ($self) = @_;

        my $ws = $self->websocket;
        $ws->add(message => sub {
            my ($conn, $msg) = @_;

            $conn->send({echo => $msg});
        });

        $self->symbiosis->mount("/ws" => $ws);
    }

Keep in mind that Plack websockets are a burden because of lack of preforking
server implementations capable of running them. If you want to use them heavily
you're better off using L<Mojolicious> instead or integrating a
L<Mojo::Server::Hypnotoad> with a small Mojo application alongside Kelp as a
websocket handler.

=head2 Deploying

Deploying a Kelp application is done the same way any other Plack application is
deployed:

    > plackup -E deployment -s Gazelle app.psgi

In production environments, it is usually a good idea to set up a proxy between
the PSGI server and the World Wide Web. Popular choices are I<apache2> and
I<nginx>. To get full information about incoming requests, you'll also need to
use L<Plack::Middleware::ReverseProxy>.

    # app.psgi

    builder {
        enable_if { ! $_[0]->{REMOTE_ADDR} || $_[0]->{REMOTE_ADDR} =~ /127\.0\.0\.1/ }
        "Plack::Middleware::ReverseProxy";
        $app->run;
    };

(REMOTE_ADDR is not set at all when using the proxy via filesocket).

=head2 Changing the default logging

Default log format can be modified by configuring the C<Logger> module. See
L<Kelp::Module::Logger/date_format> and L<Kelp::Module::Logger/log_format>.
Alternatively, L<Log::Dispatch> can be configured with its own callback to
format the message to be logged.

Access logs reported by Kelp through C<Logger> can be modified or disabled by
writing your own customized L<Kelp/before_dispatch> method (not calling the
parent version).

    sub before_dispatch {} # enough to disable the access logs

=head2 Using sessions