X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FWeb%2FSimple.pm;fp=lib%2FWeb%2FSimple.pm;h=890a339ff4981cae78173d0340dc52a718af7488;hb=582ee8ea115783f1b2a34e41c8fbf22527d43916;hp=715cd3ee0b26046b4743daee00a103da2d28e0a5;hpb=24ecd3bd2cf188c1909b62228a55dd6b5eca3d2e;p=catagits%2FWeb-Simple.git

diff --git a/lib/Web/Simple.pm b/lib/Web/Simple.pm
index 715cd3e..890a339 100644
--- a/lib/Web/Simple.pm
+++ b/lib/Web/Simple.pm
@@ -63,7 +63,7 @@ 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
+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.
 
@@ -99,12 +99,12 @@ C<warnings> pragma, so you can skip the usual:
   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;
@@ -239,7 +239,7 @@ somewhere will convert it to something useful.  This allows:
   }
 
 An alternative to using prototypes to declare a match specification for a given
-route is to provide a Dancer like key-value list:
+route is to provide a L<Dancer>-like key-value list:
 
   sub dispatch_request {
     my $self = shift;
@@ -250,7 +250,7 @@ route is to provide a Dancer like key-value list:
   }
 
 This can be useful in situations where you are generating a dispatch table
-programmatically, where setting a subroutines protoype is difficult.
+programmatically, where setting a subroutine's protoype is difficult.
 
 to render a user object to HTML, if there is an incoming URL such as:
 
@@ -260,11 +260,11 @@ This works because as we descend down the dispachers, we first match
 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 objects are treated specially - a C<Plack::Component> object
+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 {
@@ -328,7 +328,7 @@ with that request method.
 
   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:
 
@@ -336,7 +336,7 @@ 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/*/*) {
@@ -375,7 +375,7 @@ 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
@@ -437,7 +437,7 @@ match, so:
     "I match anything capturing { allofit => \$whole_path }"
   }
 
-In the specific case of a simple single-* match, the * may be omitted, to
+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) {
@@ -478,7 +478,7 @@ will match any extension and supplies the extension as a match argument.
 
 =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
@@ -523,7 +523,7 @@ would write:
 
 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) = @_;
@@ -539,9 +539,9 @@ You can also mix these, so:
   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 B<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
@@ -558,8 +558,8 @@ 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
+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
@@ -576,28 +576,29 @@ filename to make copying it somewhere else easier to handle.
 
 =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/*) {