Articulate

 view release on metacpan or  search on metacpan

README.md  view on Meta::CPAN

# Articulate, a Lightweight Perl CMS Framework

## Synopsis

Articulate provides a content management service for your web app. Lightweight means placing minimal demands on your app while maximising 'whipuptitude': it gives you a single interface in code to a framework that's totally modular underneath, and it...

You don't need to redesign your app around Articulate, it's a service that you call on when you need it, and all the 'moving parts' can be switched out if you want to do things your way.

It's written in Perl, the fast, reliable 'glue language' that's perfect for agile web development projects, and currently runs on the Dancer1 and Dancer2 web frameworks.

## Caveat

> Warning:
>
> This is work in progress! It's alpha-stage software and important things WILL change.

lib/Articulate.pm  view on Meta::CPAN

  # (in bin/app.pl)
  use Dancer;
  use Dancer::Plugin::Articulate;
  articulate_app->enable;
  dance;

B<Articulate> provides a content management service for your web app.
It's lightweight, i.e. it places minimal demands on your app while
maximising 'whipuptitude': it gives you a single interface in code to a
framework that's totally modular underneath, and it won't claim any URL
endpoints for itself.

You don't need to redesign your app around Articulate, it's a service
that you call on when you need it, and all the 'moving parts' can be
switched out if you want to do things your way.

It's written in Perl, the fast, reliable 'glue language' that's perfect
for agile web development projects, and currently runs on the L<Dancer>
and L<Dancer2> web frameworks.

=head1 GETTING STARTED

lib/Articulate.pm  view on Meta::CPAN

need is in C<config.yml>, and you can replace components with ones
you've written if your app needs to do different things.

=head2 Request/Response lifecycle summary

In a B<route>, you parse user input and pick the parameters you want to
send to the B<service>. Have a look at
L<Articulate::Routes::Transparent> for some examples. The intention is
that routes are as 'thin' as possible: business logic should all be
done by some part of the service and not in the route handler. The
route handler maps endpoints (URLs) to service requests; structured
responses are passed back as return values and are picked up by the
B<serialiser>.

B<Routes> pass B<requests> to B<services>. A B<request> contains a
B<verb> (like C<create>) and B<data> (like the B<location> you want to
create it at and the B<content> you want to place there). See
L<Articulate::Request> for more details.

The B<service> is responsible for handling requests for managed
content. L<Articulate::Service> B<delegates> to a service B<provider>,

lib/Articulate/Construction/LocationBased.pm  view on Meta::CPAN

=head1 NAME

Articulate::Construction::LocationBased - Create an item based on its
location

=head1 ATTRIBUTES

=head3 types

This should be a hashref mapping types to class names to be used in
constructors, where a type in this case is the penultimate endpoint of
locations with an even number of parts

So:

  article: Articulate::Item::Article

...would result in C</article/foo> or C<zone/public/article/foo>
becoming C<Articulate::Item::Article>s but not C<article>,
C<zone/article>, or C<zone/public/article>.