/ 
OpusVL-AppKit-2.28
River stage zero No dependents
/ OpusVL::AppKit

NAME

OpusVL::AppKit

VERSION

version 2.28

DESCRIPTION

AppKit is based on CatalystX::AppBuilder, and includes some modules for common tasks. The idea is that you produce a thin AppKit application, and stick multiple modules together.

We recommend Dist::Zilla to get you started on AppKit. That's because we've made minting profiles so we don't have to explain how it works.

$ dzil new -PAppKit MyApp
$ dzil new -PAppKitX MyApp::AppKitX::NewModularFeature

See Dist::Zilla::MintingProfile::AppKit and Dist::Zilla::MintingProfile::AppKitX.

Whenever you mint a new AppKit application, you'll end up with a common set of files:

MyApp.pm:

package MyApp;
use strict;
use warnings;
use MyApp::Builder;

our $VERSION='0.001';

my $builder = MyApp::Builder->new(
    appname => __PACKAGE__,
    version => $VERSION
);

$builder->bootstrap;

1;

MyApp/Builder.pm:

(see also "Builder")

package MyApp::Builder;
use Moose;
extends 'OpusVL::AppKit::Builder';
override _build_superclasses => sub 
{
    return [ 'OpusVL::AppKit' ]
};

override _build_config => sub
{
    my $self   = shift;
    my $config = super();

    $config->{'Controller::Login'} =
    {
        traits => '+OpusVL::AppKit::TraitFor::Controller::Login::NewSessionIdOnLogin',
    };

    $config->{'View::CMS::Page'}->{AUTO_FILTER} = 'html';

    return $config;
};

myapp.conf:

name MyApp

<Model::CMS>
    connect_info dbi:SQLite:t/db/test.db
    connect_info username
    connect_info password
</Model::CMS>

<Model::AppKitAuthDB>
    connect_info dbi:SQLite:t/db/test.db
    connect_info username
    connect_info password
</Model::AppKitAuthDB>

NAME

OpusVL::AppKit - Catalyst based application

AppKitX

AppKitX is the namespace we use for the individual modules from which your application is built. Each of this is almost an entire Catalyst application per se; except that it doesn't inherit from Catalyst itself, and requires marshalling by means of a Builder class.

We generally recommend keeping things as separate as possible, so we normally have:

An AppKitX distribution for each logical chunk of the site
A DB distribution, usually a DBIx::Class distribution that stands independently of the application itself
An AppKitX::DB distribution, which provides the Catalyst::Model for the aforementioned DB distribution.

For example, once we've created MyApp, we would create MyApp::AppKitX::SomeModule, MyApp::DB, and MyApp::AppKitX::DB.

There will be many MyApp::AppKitX::SomeModule style distributions; and possibly some MyCompany::AppKitX::SomeModule distributions, for common modules.

Builder

The builder is provided as a skeleton, but this is where you decide which modules get loaded. To do so, you override a method in MyApp/Builder.pm.

override _build_plugins => sub {
    my $plugins = super();
    return [ @$plugins, qw/
        MyApp::AppKitX::Plugin1
        MyApp::AppKitX::Plugin2
    / ];
}

This is all that's required to connect those plugins together - an app with a builder with this method, listing them.

SEE ALSO

OpusVL::AppKit::Plugin::AppKit
OpusVL::AppKit::Base::Controller::GUI
OpusVL::AppKit::Controller::Root
Catalyst

SUPPORT

Support can be garnered by use of the GitHub issue tracker at https://github.com/OpusVL/OpusVL-AppKit/issues

AUTHOR

OpusVL - www.opusvl.com

COPYRIGHT AND LICENSE

This software is copyright (c) 2010 by OpusVL - www.opusvl.com.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.