use Moo ();
use Web::Dispatch::Wrapper ();
-our $VERSION = '0.009';
+our $VERSION = '0.020';
sub import {
my ($class, $app_package) = @_;
$INC{"${name}.pm"} = 'Set by "use Web::Simple;" invocation';
}
+1;
+
=head1 NAME
Web::Simple - A quick and easy way to build simple web applications
#!/usr/bin/env perl
package HelloWorld;
- use Web::Simple
+ use Web::Simple;
sub dispatch_request {
sub (GET) {
this file will also act as a class module, so you can save it as HelloWorld.pm
and use it as-is in test scripts or other deployment mechanisms.
-Note that you should retain the ->run_if_script even if your app is a
+Note that you should retain the C<< ->run_if_script >> even if your app is a
module, since this additionally makes it valid as a .psgi file, which can
be extremely useful during development.
use warnings FATAL => 'aa';
provided you 'use Web::Simple' at the top of the file. Note that we turn
-on *fatal* warnings so if you have any warnings at any point from the file
+on B<fatal> warnings so if you have any warnings at any point from the file
that you did 'use Web::Simple' in, then your application will die. This is,
so far, considered a feature.
When we inherit from L<Web::Simple::Application> we also use L<Moo>, which is
-the the equivalent of:
+the equivalent of:
{
package NameOfApplication;
is encountered in other code.
+One important thing to remember when using
+
+ NameOfApplication->run_if_script;
+
+At the end of your app is that this call will create an instance of your app
+for you automatically, regardless of context. An easier way to think of this
+would be if the method were more verbosely named
+
+ NameOfApplication->run_request_if_script_else_turn_coderef_for_psgi;
+
=head1 DISPATCH STRATEGY
L<Web::Simple> despite being straightforward to use, has a powerful system
...
}
+Well, a sub is a valid PSGI response too (for ultimate streaming and async
+cleverness). If you want to return a PSGI sub you have to wrap it into an
+array ref.
+
+ sub dispatch_request {
+ [ sub {
+ my $respond = shift;
+ # This is pure PSGI here, so read perldoc PSGI
+ } ]
+ }
+
If you return a subroutine with a prototype, the prototype is treated
as a match specification - and if the test is passed, the body of the
-sub is called as a method any matched arguments (see below for more details).
+sub is called as a method and passed any matched arguments (see below for more details).
-You can also return a plain subroutine which will be called with just $env
-- remember that in this case if you need $self you -must- close over it.
+You can also return a plain subroutine which will be called with just C<$env>
+- remember that in this case if you need C<$self> you B<must> close over it.
If you return a normal object, L<Web::Simple> will simply return it upwards on
the assumption that a response_filter (or some arbitrary L<Plack::Middleware>)
C<sub (.html)>, which adds a C<response_filter> (basically a specialized routine
that follows the L<Plack::Middleware> specification), and then later we also
match C<sub (/user/*)> which gets a user and returns that as the response.
-This user object 'bubbles up' through all the wrapping middleware until it hits
+This user object "bubbles up" through all the wrapping middleware until it hits
the C<response_filter> we defined, after which the return is converted to a
true html response.
-However, two types of object are treated specially - a Plack::App object
-will have its C<->to_app> method called and be used as a dispatcher:
+However, two types of objects are treated specially - a L<Plack::Component> object
+will have its C<to_app> method called and be used as a dispatcher:
sub dispatch_request {
my $self = shift;
...
}
-A Plack::Middleware object will be used as a filter for the rest of the
+A L<Plack::Middleware> object will be used as a filter for the rest of the
dispatch being returned into:
## responds to /admin/track_usage AND /admin/delete_accounts
},
}
-Note that this is for the dispatch being -returned- to, so if you want to
+Note that this is for the dispatch being B<returned> to, so if you want to
provide it inline you need to do:
## ALSO responds to /admin/track_usage AND /admin/delete_accounts
=head2 Web::Simple match specifications
+Even though the following examples all use subroutine prototypes, an
+alternative to declare a match specification for a given route is to provide a
+L<Dancer>-like key-value list:
+
+ sub dispatch_request {
+ my $self = shift;
+ (
+ '.html' => sub { ... },
+ 'GET + /user/*' => sub { ... },
+ ## equivalent to:
+ # sub (.html) { ... },
+ # sub (GET + /user/*) { ... },
+ )
+ }
+
+This can be useful in situations where you are generating a dispatch table
+programmatically, where setting a subroutine's protoype is difficult.
+
=head3 Method matches
sub (GET) {
sub (/login) {
-A match specification beginning with a / is a path match. In the simplest
+A match specification beginning with a C</> is a path match. In the simplest
case it matches a specific path. To match a path with a wildcard part, you
can do:
$self->handle_user($_[1])
This will match /user/<anything> where <anything> does not include a literal
-/ character. The matched part becomes part of the match arguments. You can
+C</> character. The matched part becomes part of the match arguments. You can
also match more than one part:
sub (/user/*/*) {
sub (/domain/*/user/*) {
my ($self, $domain, $user) = @_;
-and so on. To match an arbitrary number of parts, use -
+and so on. To match an arbitrary number of parts, use C<**>:
sub (/page/**) {
+ my ($self, $match) = @_;
-This will result in an element per /-separated part so matched. Note that
-you can do
+This will result in a single element for the entire match. Note that you can do
sub (/page/**/edit) {
to match an arbitrary number of parts up to but not including some final
part.
+Note: Since Web::Simple handles a concept of file extensions, C<*> and C<**>
+matchers will not by default match things after a final dot, and this
+can be modified by using C<*.*> and C<**.*> in the final position, e.g.:
+
+ /one/* matches /one/two.three and captures "two"
+ /one/*.* matches /one/two.three and captures "two.three"
+ /** matches /one/two.three and captures "one/two"
+ /**.* matches /one/two.three and captures "one/two.three"
+
Finally,
sub (/foo/...) {
-Will match /foo/ on the beginning of the path -and- strip it. This is designed
-to be used to construct nested dispatch structures, but can also prove useful
-for having e.g. an optional language specification at the start of a path.
+Will match C</foo/> on the beginning of the path B<and> strip it. This is
+designed to be used to construct nested dispatch structures, but can also prove
+useful for having e.g. an optional language specification at the start of a
+path.
-Note that the '...' is a "maybe something here, maybe not" so the above
+Note that the C<...> is a "maybe something here, maybe not" so the above
specification will match like this:
/foo # no match
/foo/ # match and strip path to '/'
/foo/bar/baz # match and strip path to '/bar/baz'
-Note: Since Web::Simple handles a concept of file extensions, * and **
-matchers will not by default match things after a final dot, and this
-can be modified by using *.* and **.* in the final position, i.e.:
+Almost the same,
- /one/* matches /one/two.three and captures "two"
- /one/*.* matches /one/two.three and captures "two.three"
- /** matches /one/two.three and captures "one/two"
- /**.* matches /one/two.three and captures "one/two.three"
+ sub (/foo...) {
+
+Will match on C</foo/bar/baz>, but also include C</foo>. Otherwise it
+operates the same way as C</foo/...>.
+
+ /foo # match and strip path to ''
+ /foo/ # match and strip path to '/'
+ /foo/bar/baz # match and strip path to '/bar/baz'
+
+Please note the difference between C<sub(/foo/...)> and C<sub(/foo...)>. In
+the first case, this is expecting to find something after C</foo> (and fails to
+match if nothing is found), while in the second case we can match both C</foo>
+and C</foo/more/to/come>. The following are roughly the same:
+
+ sub (/foo) { 'I match /foo' },
+ sub (/foo/...) {
+ sub (/bar) { 'I match /foo/bar' },
+ sub (/*) { 'I match /foo/{id}' },
+ }
+
+Versus
+
+ sub (/foo...) {
+ sub (~) { 'I match /foo' },
+ sub (/bar) { 'I match /foo/bar' },
+ sub (/*) { 'I match /foo/{id}' },
+ }
+
+You may prefer the latter example should you wish to take advantage of
+subdispatchers to scope common activities. For example:
+
+ sub (/user...) {
+ my $user_rs = $schema->resultset('User');
+ sub (~) { $user_rs },
+ sub (/*) { $user_rs->find($_[1]) },
+ }
+
+You should note the special case path match C<sub (~)> which is only meaningful
+when it is contained in this type of path match. It matches to an empty path.
+
+=head4 Naming your patch matches
+
+Any C<*>, C<**>, C<*.*>, or C<**.*> match can be followed with C<:name> to make it into a named
+match, so:
+
+ sub (/*:one/*:two/*:three/*:four) {
+ "I match /1/2/3/4 capturing { one => 1, two => 2, three => 3, four => 4 }"
+ }
+
+ sub (/**.*:allofit) {
+ "I match anything capturing { allofit => \$whole_path }"
+ }
+
+In the specific case of a simple single-C<*> match, the C<*> may be omitted, to
+allow you to write:
+
+ sub (/:one/:two/:three/:four) {
+ "I match /1/2/3/4 capturing { one => 1, two => 2, three => 3, four => 4 }"
+ }
+
+=head4 C</foo> and C</foo/> are different specs
+
+As you may have noticed with the difference between C<sub(/foo/...)> and
+C<sub(/foo...)>, trailing slashes in path specs are significant. This is
+intentional and necessary to retain the ability to use relative links on
+websites. Let's demonstrate on this link:
+
+ <a href="bar">bar</a>
+
+If the user loads the url C</foo/> and clicks on this link, they will be
+sent to C</foo/bar>. However when they are on the url C</foo> and click this
+link, then they will be sent to C</bar>.
+
+This makes it necessary to be explicit about the trailing slash.
=head3 Extension matches
sub (.html) {
will match .html from the path (assuming the subroutine itself returns
-something, of course). This is normally used for rendering - e.g.
+something, of course). This is normally used for rendering - e.g.:
sub (.html) {
response_filter { $self->render_html($_[1]) }
=head3 Query and body parameter matches
-Query and body parameters can be match via
+Query and body parameters can be matched via
sub (?<param spec>) { # match URI query
sub (%<param spec>) { # match body params
The body spec will match if the request content is either
application/x-www-form-urlencoded or multipart/form-data - the latter
-of which is required for uploads, which are now handled experimentally
-- see below.
+of which is required for uploads - see below.
-The param spec is elements of one of the following forms -
+The param spec is elements of one of the following forms:
param~ # optional parameter
param= # required parameter
* # include all other parameters in hashref
@* # include all other parameters as multiple in hashref
-separated by the & character. The arguments added to the request are
-one per non-:/* parameter (scalar for normal, arrayref for multiple),
-plus if any :/* specs exist a hashref containing those values.
+separated by the C<&> character. The arguments added to the request are
+one per non-C<:>/C<*> parameter (scalar for normal, arrayref for multiple),
+plus if any C<:>/C<*> specs exist a hashref containing those values.
Please note that if you specify a multiple type parameter match, you are
ensured of getting an arrayref for the value, EVEN if the current incoming
request has only one value. However if a parameter is specified as single
and multiple values are found, the last one will be used.
-For example to match a page parameter with an optional order_by parameter one
+For example to match a C<page> parameter with an optional C<order_by> parameter one
would write:
sub (?page=&order_by~) {
to implement paging and ordering against a L<DBIx::Class::ResultSet> object.
-Another Example: To get all parameters as a hashref of arrayrefs, write:
+Another example: To get all parameters as a hashref of arrayrefs, write:
sub(?@*) {
my ($self, $params) = @_;
sub (?foo=&@bar~&:coffee=&@*) {
my ($self, $foo, $bar, $params);
-where $bar is an arrayref (possibly an empty one), and $params contains
-arrayref values for all parameters -not- mentioned and a scalar value for
-the 'coffee' parameter.
+where C<$bar> is an arrayref (possibly an empty one), and C<$params> contains
+arrayref values for all parameters B<not> mentioned and a scalar value for the
+C<coffee> parameter.
Note, in the case where you combine arrayref, single parameter and named
hashref style, the arrayref and single parameters will appear in C<@_> in the
order you defined them in the protoype, but all hashrefs will merge into a
single C<$params>, as in the example above.
-=head3 Upload matches (EXPERIMENTAL)
-
-Note: This feature is experimental. This means that it may not remain
-100% in its current form. If we change it, notes on updating your code
-will be added to the L</CHANGES BETWEEN RELEASES> section below.
+=head3 Upload matches
sub (*foo=) { # param specifier can be anything valid for query or body
Note that this match type will succeed in two circumstances where you might
not expect it to - first, when the field exists but is not an upload field
and second, when the field exists but the form is not an upload form (i.e.
-content type "application/x-www-form-urlencoded" rather than
-"multipart/form-data"). In either of these cases, what you'll get back is
+content type C<application/x-www-form-urlencoded> rather than
+C<multipart/form-data>). In either of these cases, what you'll get back is
a C<Web::Dispatch::NotAnUpload> object, which will C<die> with an error
pointing out the problem if you try and use it. To be sure you have a real
upload object, call
=head3 Combining matches
-Matches may be combined with the + character - e.g.
+Matches may be combined with the C<+> character - e.g.
sub (GET + /user/*) {
-to create an AND match. They may also be combined withe the | character - e.g.
+to create an AND match. They may also be combined with the C<|> character -
+e.g.
sub (GET|POST) {
-to create an OR match. Matches can be nested with () - e.g.
+to create an OR match. Matches can be nested with C<()> - e.g.
sub ((GET|POST) + /user/*) {
-and negated with ! - e.g.
+and negated with C<!> - e.g.
sub (!/user/foo + /user/*) {
-! binds to the immediate rightmost match specification, so if you want
+C<!> binds to the immediate rightmost match specification, so if you want
to negate a combination you will need to use
sub ( !(POST|PUT|DELETE) ) {
-and | binds tighter than +, so
+and C<|> binds tighter than C<+>, so
sub ((GET|POST) + /user/*) {
=head3 Whitespace
-Note that for legibility you are permitted to use whitespace -
+Note that for legibility you are permitted to use whitespace:
sub (GET + /user/*) {
sub (GET+/user/*) {
+=head3 Accessing parameters via C<%_>
+
+If your dispatch specification causes your dispatch subroutine to receive
+a hash reference as its first argument, the contained named parameters
+will be accessible via C<%_>.
+
+This can be used to access your path matches, if they are named:
+
+ sub (GET + /foo/:path_part) {
+ [ 200,
+ ['Content-type' => 'text/plain'],
+ ["We are in $_{path_part}"],
+ ];
+ }
+
+Or, if your first argument would be a hash reference containing named
+query parameters:
+
+ sub (GET + /foo + ?:some_param=) {
+ [ 200,
+ ['Content-type' => 'text/plain'],
+ ["We received $_{some_param} as parameter"],
+ ];
+ }
+
+Of course this also works when all you are doing is slurping the whole set
+of parameters by their name:
+
+ sub (GET + /foo + ?*) {
+ [ 200,
+ ['Content-type' => 'text/plain'],
+ [exists($_{foo}) ? "Received a foo: $_{foo}" : "No foo!"],
+ ],
+ }
+
+Note that only the first hash reference will be available via C<%_>. If
+you receive additional hash references, you will need to access them as
+usual.
+
=head3 Accessing the PSGI env hash
In some cases you may wish to get the raw PSGI env hash - to do this,
-you can either use a plain sub -
+you can either use a plain sub:
sub {
my ($env) = @_;
...
}
-or use the PSGI_ENV constant exported to retrieve it:
+or use the C<PSGI_ENV> constant exported to retrieve it from C<@_>:
sub (GET + /foo + ?some_param=) {
my $param = $_[1];
of continuing dispatch re-delegates it to the start of the dispatch process,
but with the path of the request altered to the supplied URL.
-Thus if you receive a POST to '/some/url' and return a redispatch to
-'/other/url', the dispatch behaviour will be exactly as if the same POST
-request had been made to '/other/url' instead.
+Thus if you receive a POST to C</some/url> and return a redispatch to
+C</other/url>, the dispatch behaviour will be exactly as if the same POST
+request had been made to C</other/url> instead.
Note, this is not the same as returning an HTTP 3xx redirect as a response;
rather it is a much more efficient internal process.
...
}
-Note that this method is still -returning- the dispatch code - just like
-dispatch did.
+Note that this method is still B<returning> the dispatch code - just like
+C<dispatch> did.
-Also note that you need the 'my $self = shift' since the magic $self
+Also note that you need the C<< my $self = shift >> since the magic $self
variable went away.
=item * the magic $self variable went away.
-Just add 'my $self = shift;' while writing your 'sub dispatch_request {'
+Just add C<< my $self = shift; >> while writing your C<< sub dispatch_request { >>
like a normal perl method.
=item * subdispatch deleted - all dispatchers can now subdispatch
Josh McMichael <jmcmicha@linus222.gsc.wustl.edu>
-Justin Hunter <justin.d.hunter@gmail.com>
+Justin Hunter (arcanez) <justin.d.hunter@gmail.com>
Kjetil Kjernsmo <kjetil@kjernsmo.net>
Robin Edwards <robin.ge@gmail.com>
+Andrew Rodland (hobbs) <andrew@cleverdomain.org>
+
+Robert Sedlacek (phaylon) <r.sedlacek@shadowcat.co.uk>
+
=head1 COPYRIGHT
-Copyright (c) 2010 the Web::Simple L</AUTHOR> and L</CONTRIBUTORS>
+Copyright (c) 2011 the Web::Simple L</AUTHOR> and L</CONTRIBUTORS>
as listed above.
=head1 LICENSE
as perl itself.
=cut
-
-1;
projects / catagits/Web-Simple.git / blobdiff