The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.

NAME

Leyland - Plack-based framework for RESTful web applications

VERSION

version 0.001007

SYNOPSIS

        # in app.psgi:

        #!/usr/bin/perl -w

        use strict;
        use warnings;
        use MyApp;

        my $config = {
                app => 'MyApp',
                views => ['Tenjin'],
                locales => './i18n',
        };

        my $myapp = MyApp->new(config => $config);

        my $app = sub {
                $myapp->handle(shift);
        };

DESCRIPTION

Leyland is a Plack-based application framework for building truely RESTful, MVC-style web applications.

"Another application framework?" you ask? Well yes! You see, after several years of Catalyst development, I grew tired of Catalyst's bloat, and the fact that it made it very hard (pretty much impossible if you ask me) to create truely RESTful applications. I then moved for a short while to Dancer, which had a nice syntax for defining routes and had at least some REST properties, but I quickly found it didn't fit my needs as well, and that it also made it very difficult to write truely RESTful applications. I also really missed Catalyst's "context object" and some of its other features, and simply couldn't get used to Dancer's whole functional syntax you're supposed to use inside your routes. While there were quite a few other options on CPAN, I didn't like any of them, plus pretty much none of them were native Plack frameworks, which for me is a bit of a minus (can't blame them though as most of them predate Plack), so I decided to create my own framework, based on Plack and designed to my liking. This is the mess that I've created. You will find that it mostly resembles Catalyst, while providing a syntax mostly similar to Dancer, but with a lot of crazy ideas of its own.

FEATURES

  • Build truely RESTful web applications - Leyland was designed from the ground up according to the Representational State Transfer style of software architecture. Leyland applications perform real HTTP negotiations, (can) provide different representations of the same resource easily, respond with proper HTTP status codes, throw real HTTP exceptions, etc.

  • Automatic data (de)serialization - Leyland does by itself the boring task of serializing resources to representations in the format your client wants to receive, like JSON and XML. It will also deserialize JSON/XML requests to Perl data-structures automatically.

  • Pure UTF-8 - Leyland applications are pure UTF-8. Anything your application receives is automatically UTF-8 decoded, and anything your application sends is automatically UTF-8 encoded. Leyland apps will not accept, nor provide, content in a different character set. If you want to use different/multiple encodings, then Leyland is not for you.

  • Localize for the client, not the server - Pretty much every other application framework only concerns itself with localizing the application to the locale of the machine on which it is running. I find that this is rarely useful nor interesting to the application developer. Leyland localizes for the client, not the server. If the client wants to view your application (which may be a simple website) in Hebrew, and your application supports Hebrew, then you can easily provide him with Hebrew representations. Leyland uses Locale::Wolowitz for this purpose.

  • Easy deployment and middleware support via Plack - Leyland doesn't support Plack, it is dependant on it. Leyland's entire session support, for example, depends on Plack's Session middleware. Use the full power of Plack in your Leyland application.

  • Less code, better programs - One thing I really hated about Catalyst was that I had to create stupid pointless classes that don't do anything but wrap a base class, just so I can have a new view class or something. While not as lightweight as Dancer, Leyland does a lot of the boring work for you, so you can concentrate more on your application.

  • Flexible, extensible, unbreakable - Well, it's not unbreakable, but Leyland was designed to be as flexible and as extensible as possible - where flexibility matters, and strict - where constistency and convention are appropriate. Leyland goes to great lengths to give you the ability to do things the way you want to, and more importantly - the way your end-users want to. Your applications listen to your users' preferences and automatically decide on a suitable course of action. Leyland is also Moose based, making it easy to extend and tweak its behavior.

  • Doesn't have a pony - You don't really need a pony, do you?

STATUS

Development of Leyland began August 2010. I have been using it extensively for several projects, some of them already in production. Therefore, the API has somewhat stabilized and I do not consider it in alpha status. That said, Leyland still is immature, and I cannot guarantee that API changes won't be made, nor that it is bug free or even secure enough. If you're thinking of using Leyland for a production project, please test it thoroughly beforehand.

MANUAL / TUTORIAL / GUIDE / GIBBERISH

To learn about using Leyland, please refer to the Leyland::Manual. The documentation of this distribution's classes is for reference only, the manual is where you're most likely to find your answers. Or not.

WHAT'S WITH THE NAME?

Leyland is named after Mr. Bean's clunker of a car - the British Leyland Mini 1000. I don't know why.

ATTRIBUTES

config

A hash-ref of configuration options for the application. If not provided, a default configuration will be used.

context_class

The name of the class to be used as the context class for every request. Defaults to Leyland::Context. If provided, the class must extend Leyland::Context.

name

The package name of the application, for example MyApp or My::App. Automatically created from the app's configuration. If config doesn't define a name, 'Leyland' will be used.

log

A logger object that does Leyland::Logger, providing the application with logging capabilities. Automatically built from the app's config, unless config doesn't define a logger, in which case Leyland::Logger::STDERR will be used.

localizer

If application config defines a path for localization files, this will hold a Leyland::Localizer object, which is based on Locale::Wolowitz.

views

An array refernce of all Leyland::View classes enabled in the app's configuration. If none defined, Tenjin is used by default.

routes

A Tie::IxHash object holding all routes defined in the application's controllers. Automatically created, not to be used directly by applications.

req_counter

An integer representing the number of requests handled by the application. Automatically created.

cwe

The plack environment in which the application is running. This is the PLACK_ENV environment variable. Defaults to "development" unless you've provided a specific value to plackup (via the -E switch or by changing PLACK_ENV directly).

CLASS METHODS

new( [ %attrs ] )

Creates a new instance of this class. None of the attributes are required (in fact, you shouldn't pass most of them), but you will mostly pass the config attribute, and possibly the context_class attribute.

OBJECT METHODS

setup()

Meant to be overridden by applications, this is automatically called right after the application has been initialized, so it is useful for one-time initializations your application might need to perform. If not overridden, this method does nothing.

handle( \%env )

Receives a Plack environment hash-ref of an HTTP request, creates a new instance of the application's context class (most probably Leyland::Context), performs HTTP negotiations and finds routes matching the request. If any are found, the first one is invoked and an HTTP response is generated and returned.

You should note that requests to paths that end with a slash will automatically be redirected without the trailing slash.

This method will probably be called from app.psgi.

has_localizer()

Returns a true value if the application has a localizer.

has_views()

Returns a true value if the application has any view classes.

has_routes()

Returns a true value if the application has any routes defined in its controllers.

INTERNAL METHODS

The following methods are only to be used internally.

BUILD()

Automatically called by Moose after instance creation, this method loads the context class, application logger, localizer, controllers and views. It then find all routes in the controllers, runs the application's setup() method, and prints a nice info table to the log.

_handle_exception( $c, $exp )

Receives exceptions thrown by the application (including run-time errors) and generates an HTTP response with the error information, in a format recognizable by the client.

_default_config()

Returns a default configuration hash-ref.

_autolog( $msg )

Used by Text::SpanningTable when printing the application's info table.

_initial_debug_info()

Prints an info table of the application after initialization.

AUTHOR

Ido Perlmuter, <ido at ido50.net>

ACKNOWLEDGMENTS

I wish to thank the following people:

BUGS

Please report any bugs or feature requests to bug-Leyland at rt.cpan.org, or through the web interface at http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Leyland. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.

SUPPORT

You can find documentation for this module with the perldoc command.

        perldoc Leyland

You can also look for information at:

LICENSE AND COPYRIGHT

Copyright 2010-2011 Ido Perlmuter.

This program is free software; you can redistribute it and/or modify it under the terms of either: the GNU General Public License as published by the Free Software Foundation; or the Artistic License.

See http://dev.perl.org/licenses/ for more information.

2 POD Errors

The following errors were encountered while parsing the POD:

Around line 658:

alternative text 'http://search.cpan.org/~sknpp/' contains non-escaped | or /

Around line 660:

alternative text 'http://search.cpan.org/~mdorman/' contains non-escaped | or /