CPAN::Groonga

ces to representations in the format your client
wants to receive, like JSON and XML. It will also automatically deserialize
JSON/XML requests coming from the client to Perl data-structures.

=item * 

he request mime types, let's
	# attempt to serialize the error ourselves if the client accepts
	# JSON or XML
	foreach (@{$c->wanted_mimes}) {
		return $c->_respond(
			$exp->code,
			{ 'Content-Type'

mime} eq 'text/html' ||
			$_->{mime} eq 'application/xhtml+xml' ||
			$_->{mime} eq 'application/json' ||
			$_->{mime} eq 'application/atom+xml' ||
			$_->{mime} eq 'application/xml';
	}

	# We do n

the
clients are web browsers, but also RSS/Atom when your clients are
feed readers and maybe even JSON if your platform has some cool AJAX admin
interface to it.

=head1 DATA SERIALIZATION

Before we 

ormat
such as XML or JSON. The reverse process is called deserialization.

Leyland takes care of both processes by itself. If you have resources for
which you wish to generate JSON/XML representations

 'applications/json'> for example, see L<Leyland::Manual::Controllers/"ROUTES">
for more information), and just return the data structure as-is from the
route. If the client accepts JSON/XML, Leyland 

tically available for you here
		$c->template('stuff.html');
	}

	post '^/$' returns 'application/json' {
		# do stuff
	}

	1;

=head1 DESCRIPTION

This module is meant to be used by <Leyland controll

ces to representations in the format your client
wants to receive, like JSON and XML. It will also automatically deserialize
JSON/XML requests coming from the client to Perl data-structures.

=item * 

TTP request and Leyland response

use Moo;
use namespace::clean;

use Carp;
use Data::Dumper;
use JSON;
use Leyland::Exception;
use Leyland::Logger;
use Module::Load;
use Text::SpanningTable;
use Try:

nvenience. You will use the C<set_user()> method
to set the value of this attribute.

=head2 json

A L<JSON::Any> object for usage by routes as they see fit.

=head2 xml

An L<XML::TreePP> object for 

eq 'Leyland::Logger' }
);

has 'json' => (
	is => 'ro',
	isa => sub { die "json must be a JSON object" unless ref $_[0] && ref $_[0] eq 'JSON' },
	default => sub { JSON->new->utf8(0)->convert_blessed 

no idea what went wrong",
			mimes => {
				'text/html' => 'error.html',
				'application/json' => 'error.json',
			},
		});

	# or you can create an error that redirects (don't do this unless
	# you 

n catches the exception and properly serializes it to a format
the client supports, such as HTML, JSON or XML (or plain text when the client
does not support any of these formats). If the request was 

turned to the browser. If the
request was initiated from a JSON client, such as with an AJAX request, then
the error will be returned in JSON format.

=head1 PRETTIFYING EXCEPTIONS

By default, when r

hash-ref passed to C<< $c->exception() >>, you can, for example, add a template
for C<application/json> requests if you see fit.

In the future, I plan to have Leyland make it easier to globally set t

new; # = MyLeylandApp

=item * Leyland no longer uses L<JSON::Any> as its JSON object. It now uses L<JSON> (which will automatically load L<JSON::XS> if available). The interface should be the same, b

robably should be aware of this change. Note, also, that C<convert_blessed> is now enabled on the JSON object.

=item * Leyland is now L<Moo>-based instead of L<Moose>-based, so it is much lighter tha

s look at a pretty complete example:

	get '^/posts$' accepts 'text/html|application/json' returns 'application/json' {
		my @posts = MyDatabase->load_posts();
		return { posts => \@posts };
	}

The a

hat
has an empty prefix). It will only accept C<text/html> or C<application/json>
from the client, and will only return JSON. The following HTTP methods
are available:

=over

=item * get: for C<GET> 

.

	post '^/posts$' returns 'application/json' {
		my @posts = $c->forward('GET:/posts');
		# do stuff with @posts
	}

	get '^/posts$' returns 'application/json' is 'internal' {
		return MyDatabase->l

e.
This is why I created L<Locale::Wolowitz>, which is a very simple localization
system based on JSON. This is also the reason why, as opposed to logging
and view classes, Leyland only provides C<Loc

layouts/ (required)
	|----------- main.html (required)
	|----- i18n/
	|-------- es.json
	|-------- he_and_it.coll.json

The C<app.psgi> file is a standard L<PSGI> application that configures and
initi

ews and templates reside. These will
mostly be HTML templates, but can actually be anything, even JSON or XML
or whatever. Views and templates are handled by Leyland's view classes,
and are rendered a

irectory. Once again, this is optional and
purely a suggestion. If used, this directory will hold JSON localization
files for localizing your application with L<Locale::Wolowitz>. See
L<Leyland::Manua

 method receives the name of a view (or "template" if you will, such
as 'index.html' or 'resource.json'), and a hash-ref of variables to be
available for the template (known as the "context"). Leyland