fix silly typo
[catagits/Web-Simple.git] / lib / Web / Simple.pm
index 91eac78..d5ca0e2 100644 (file)
@@ -6,7 +6,7 @@ use warnings::illegalproto ();
 use Moo ();
 use Web::Dispatch::Wrapper ();
 
-our $VERSION = '0.008';
+our $VERSION = '0.020';
 
 sub import {
   my ($class, $app_package) = @_;
@@ -30,40 +30,26 @@ sub _export_into {
   $INC{"${name}.pm"} = 'Set by "use Web::Simple;" invocation';
 }
 
+1;
+
 =head1 NAME
 
 Web::Simple - A quick and easy way to build simple web applications
 
-=head1 WARNING
-
-This is really quite new. If you're reading this on CPAN, it means the stuff
-that's here we're probably happy with. But only probably. So we may have to
-change stuff. And if you're reading this from git, come check with irc.perl.org
-#web-simple that we're actually sure we're going to keep anything that's
-different from the CPAN version.
-
-If we do find we have to change stuff we'll add to the
-L<CHANGES BETWEEN RELEASES> section explaining how to switch your code across
-to the new version, and we'll do our best to make it as painless as possible
-because we've got Web::Simple applications too. But we can't promise not to
-change things at all. Not yet. Sorry.
 
 =head1 SYNOPSIS
 
   #!/usr/bin/env perl
 
-  use Web::Simple 'HelloWorld';
-
-  {
-    package HelloWorld;
+  package HelloWorld;
+  use Web::Simple;
 
-    sub dispatch_request {
-      sub (GET) {
-        [ 200, [ 'Content-type', 'text/plain' ], [ 'Hello world!' ] ]
-      },
-      sub () {
-        [ 405, [ 'Content-type', 'text/plain' ], [ 'Method not allowed' ] ]
-      }
+  sub dispatch_request {
+    sub (GET) {
+      [ 200, [ 'Content-type', 'text/plain' ], [ 'Hello world!' ] ]
+    },
+    sub () {
+      [ 405, [ 'Content-type', 'text/plain' ], [ 'Method not allowed' ] ]
     }
   }
 
@@ -73,9 +59,17 @@ If you save this file into your cgi-bin as C<hello-world.cgi> and then visit:
 
   http://my.server.name/cgi-bin/hello-world.cgi/
 
-you'll get the "Hello world!" string output to your browser. For more complex
-examples and non-CGI deployment, see below. To get help with L<Web::Simple>,
-please connect to the irc.perl.org IRC network and join #web-simple.
+you'll get the "Hello world!" string output to your browser. At the same time
+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
+module, since this additionally makes it valid as a .psgi file, which can
+be extremely useful during development.
+
+For more complex examples and non-CGI deployment, see
+L<Web::Simple::Deployment>. To get help with L<Web::Simple>, please connect to
+the irc.perl.org IRC network and join #web-simple.
 
 =head1 DESCRIPTION
 
@@ -95,7 +89,7 @@ C<import> based one:
 
 This sets up your package (in this case "NameOfApplication" is your package)
 so that it inherits from L<Web::Simple::Application> and imports L<strictures>,
-as well as installs a C<PSGI_ENV> constant for convenience, as well as some 
+as well as installs a C<PSGI_ENV> constant for convenience, as well as some
 other subroutines.
 
 Importing L<strictures> will automatically make your code use the C<strict> and
@@ -109,7 +103,7 @@ on *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 <Moo>, which is
+When we inherit from L<Web::Simple::Application> we also use L<Moo>, which is
 the the equivalent of:
 
   {
@@ -138,6 +132,16 @@ so that perl will not attempt to load the application again even if
 
 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
@@ -206,12 +210,23 @@ However, generally, instead of that, you return a set of dispatch subs:
     ...
   }
 
+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>)
@@ -223,6 +238,20 @@ somewhere will convert it to something useful.  This allows:
     sub (/user/*) { $self->users->get($_[1]) },
   }
 
+An alternative to using prototypes to declare a match specification for a given
+route is to provide a Dancer like key-value list:
+
+  sub dispatch_request {
+    my $self = shift;
+    (
+      '.html' => sub { response_filter { $self->render_zoom($_[0]) } },
+      '/user/*' => sub { $self->users->get($_[1]) },
+    )
+  }
+
+This can be useful in situations where you are generating a dispatch table
+programmatically, where setting a subroutines protoype is difficult.
+
 to render a user object to HTML, if there is an incoming URL such as:
 
   http://myweb.org/user/111.html
@@ -235,8 +264,8 @@ 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 C<Plack::Component> object
+will have its C<to_app> method called and be used as a dispatcher:
 
   sub dispatch_request {
     my $self = shift;
@@ -244,7 +273,7 @@ will have its C<->to_app> method called and be used as a dispatcher:
     ...
   }
 
-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
@@ -262,7 +291,7 @@ dispatch being returned into:
     },
   }
 
-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
@@ -316,25 +345,35 @@ also match more than one part:
   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
 specification will match like this:
@@ -343,12 +382,89 @@ specification will match like this:
   /foo/        # match and strip path to '/'
   /foo/bar/baz # match and strip path to '/bar/baz'
 
+Almost the same,
+
+  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-* match, the * 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]) }
@@ -367,11 +483,11 @@ Query and body parameters can be match via
   sub (?<param spec>) { # match URI query
   sub (%<param spec>) { # match body params
 
-The body is only matched if the content type is
-application/x-www-form-urlencoded (note this means that Web::Simple does
-not yet handle uploads; this will be addressed in a later release).
+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 - 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
@@ -384,16 +500,16 @@ The param spec is elements of one of the following forms -
   *             # 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~) {
@@ -424,14 +540,40 @@ You can also mix these, so:
      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
+arrayref values for all parameters B<not> mentioned and a scalar value for
 the '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 
+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
+
+  sub (*foo=) { # param specifier can be anything valid for query or body
+
+The upload match system functions exactly like a query/body match, except
+that the values returned (if any) are C<Web::Dispatch::Upload> objects.
+
+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
+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
+
+  $upload->is_upload # returns 1 on a valid upload, 0 on a non-upload field
+
+and to get the reason why such an object is not an upload, call
+
+  $upload->reason # returns a reason or '' on a valid upload.
+
+Other than these two methods, the upload object provides the same interface
+as L<Plack::Request::Upload> with the addition of a stringify to the temporary
+filename to make copying it somewhere else easier to handle.
+
 =head3 Combining matches
 
 Matches may be combined with the + character - e.g.
@@ -479,7 +621,7 @@ which will never match!
 
 =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/*) {
 
@@ -488,17 +630,56 @@ from subroutine prototypes, so this is equivalent to
 
   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];
@@ -540,12 +721,12 @@ It creates and returns a special dispatcher that always matches, and instead
 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.  
+rather it is a much more efficient internal process.
 
 =head1 CHANGES BETWEEN RELEASES
 
@@ -563,15 +744,15 @@ dispatch {} has gone away - instead, you write:
     ...
   }
 
-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
@@ -596,6 +777,8 @@ As of 0.005, you can instead write simply:
     )
   }
 
+=back
+
 =head2 Changes since Antiquated Perl
 
 =over 4
@@ -626,7 +809,8 @@ that having a bare minimum system for writing web applications that doesn't
 drive me insane was rather nice and decided to spend my attempt at nanowrimo
 for 2009 improving and documenting it to the point where others could use it.
 
-The Antiquated Perl talk can be found at L<http://www.shadowcat.co.uk/archive/conference-video/>.
+The Antiquated Perl talk can be found at L<http://www.shadowcat.co.uk/archive/conference-video/> and the slides are reproduced in this distribution under
+L<Web::Simple::AntiquatedPerl>.
 
 =head1 COMMUNITY AND SUPPORT
 
@@ -646,15 +830,39 @@ Gitweb is on http://git.shadowcat.co.uk/ and the clone URL is:
 
 =head1 AUTHOR
 
-Matt S. Trout <mst@shadowcat.co.uk>
+Matt S. Trout (mst) <mst@shadowcat.co.uk>
 
 =head1 CONTRIBUTORS
 
-None required yet. Maybe this module is perfect (hahahahaha ...).
+Devin Austin (dhoss) <dhoss@cpan.org>
+
+Arthur Axel 'fREW' Schmidt <frioux@gmail.com>
+
+gregor herrmann (gregoa) <gregoa@debian.org>
+
+John Napiorkowski (jnap) <jjn1056@yahoo.com>
+
+Josh McMichael <jmcmicha@linus222.gsc.wustl.edu>
+
+Justin Hunter (arcanez) <justin.d.hunter@gmail.com>
+
+Kjetil Kjernsmo <kjetil@kjernsmo.net>
+
+markie <markie@nulletch64.dreamhost.com>
+
+Christian Walde (Mithaldu) <walde.christian@googlemail.com>
+
+nperez <nperez@cpan.org>
+
+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
@@ -663,5 +871,3 @@ This library is free software and may be distributed under the same terms
 as perl itself.
 
 =cut
-
-1;