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:
* http://search.cpan.org/~sknpp/ for submitting bug fixes
* http://search.cpan.org/~mdorman/ for some helpful ideas
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:
* RT: CPAN's request tracker
<http://rt.cpan.org/NoAuth/Bugs.html?Dist=Leyland>
* AnnoCPAN: Annotated CPAN documentation
<http://annocpan.org/dist/Leyland>
* CPAN Ratings
<http://cpanratings.perl.org/d/Leyland>
* Search CPAN
<http://search.cpan.org/dist/Leyland/>
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.