doc patch for '/foo...'
[catagits/Web-Simple.git] / lib / Web / Simple.pm
1 package Web::Simple;
2
3 use strictures 1;
4 use 5.008;
5 use warnings::illegalproto ();
6 use Moo ();
7 use Web::Dispatch::Wrapper ();
8
9 our $VERSION = '0.011';
10
11 sub import {
12   my ($class, $app_package) = @_;
13   $app_package ||= caller;
14   $class->_export_into($app_package);
15   eval "package $app_package; use Web::Dispatch::Wrapper; use Moo; 1"
16     or die "Failed to setup app package: $@";
17   strictures->import;
18   warnings::illegalproto->unimport;
19 }
20
21 sub _export_into {
22   my ($class, $app_package) = @_;
23   {
24     no strict 'refs';
25     *{"${app_package}::PSGI_ENV"} = sub () { -1 };
26     require Web::Simple::Application;
27     unshift(@{"${app_package}::ISA"}, 'Web::Simple::Application');
28   }
29   (my $name = $app_package) =~ s/::/\//g;
30   $INC{"${name}.pm"} = 'Set by "use Web::Simple;" invocation';
31 }
32
33 =head1 NAME
34
35 Web::Simple - A quick and easy way to build simple web applications
36
37
38 =head1 SYNOPSIS
39
40   #!/usr/bin/env perl
41
42   package HelloWorld;
43   use Web::Simple;
44
45   sub dispatch_request {
46     sub (GET) {
47       [ 200, [ 'Content-type', 'text/plain' ], [ 'Hello world!' ] ]
48     },
49     sub () {
50       [ 405, [ 'Content-type', 'text/plain' ], [ 'Method not allowed' ] ]
51     }
52   }
53
54   HelloWorld->run_if_script;
55
56 If you save this file into your cgi-bin as C<hello-world.cgi> and then visit:
57
58   http://my.server.name/cgi-bin/hello-world.cgi/
59
60 you'll get the "Hello world!" string output to your browser. At the same time
61 this file will also act as a class module, so you can save it as HelloWorld.pm
62 and use it as-is in test scripts or other deployment mechanisms.
63
64 Note that you should retain the ->run_if_script even if your app is a
65 module, since this additionally makes it valid as a .psgi file, which can
66 be extremely useful during development.
67
68 For more complex examples and non-CGI deployment, see
69 L<Web::Simple::Deployment>. To get help with L<Web::Simple>, please connect to
70 the irc.perl.org IRC network and join #web-simple.
71
72 =head1 DESCRIPTION
73
74 The philosophy of L<Web::Simple> is to keep to an absolute bare minimum for
75 everything. It is not designed to be used for large scale applications;
76 the L<Catalyst> web framework already works very nicely for that and is
77 a far more mature, well supported piece of software.
78
79 However, if you have an application that only does a couple of things, and
80 want to not have to think about complexities of deployment, then L<Web::Simple>
81 might be just the thing for you.
82
83 The only public interface the L<Web::Simple> module itself provides is an
84 C<import> based one:
85
86   use Web::Simple 'NameOfApplication';
87
88 This sets up your package (in this case "NameOfApplication" is your package)
89 so that it inherits from L<Web::Simple::Application> and imports L<strictures>,
90 as well as installs a C<PSGI_ENV> constant for convenience, as well as some
91 other subroutines.
92
93 Importing L<strictures> will automatically make your code use the C<strict> and
94 C<warnings> pragma, so you can skip the usual:
95
96   use strict;
97   use warnings FATAL => 'aa';
98
99 provided you 'use Web::Simple' at the top of the file. Note that we turn
100 on *fatal* warnings so if you have any warnings at any point from the file
101 that you did 'use Web::Simple' in, then your application will die. This is,
102 so far, considered a feature.
103
104 When we inherit from L<Web::Simple::Application> we also use L<Moo>, which is
105 the the equivalent of:
106
107   {
108     package NameOfApplication;
109     use Moo;
110     extends 'Web::Simple::Application';
111   }
112
113 So you can use L<Moo> features in your application, such as creating attributes
114 using the C<has> subroutine, etc.  Please see the documentation for L<Moo> for
115 more information.
116
117 It also exports the following subroutines for use in dispatchers:
118
119   response_filter { ... };
120
121   redispatch_to '/somewhere';
122
123 Finally, import sets
124
125   $INC{"NameOfApplication.pm"} = 'Set by "use Web::Simple;" invocation';
126
127 so that perl will not attempt to load the application again even if
128
129   require NameOfApplication;
130
131 is encountered in other code.
132
133 =head1 DISPATCH STRATEGY
134
135 L<Web::Simple> despite being straightforward to use, has a powerful system
136 for matching all sorts of incoming URLs to one or more subroutines.  These
137 subroutines can be simple actions to take for a given URL, or something
138 more complicated, including entire L<Plack> applications, L<Plack::Middleware>
139 and nested subdispatchers.
140
141 =head2 Examples
142
143  sub dispatch_request {
144    # matches: GET /user/1.htm?show_details=1
145    #          GET /user/1.htm
146    sub (GET + /user/* + ?show_details~ + .htm|.html|.xhtml) {
147      my ($self, $user_id, $show_details) = @_;
148      ...
149    },
150    # matches: POST /user?username=frew
151    #          POST /user?username=mst&first_name=matt&last_name=trout
152    sub (POST + /user + ?username=&*) {
153       my ($self, $username, $misc_params) = @_;
154      ...
155    },
156    # matches: DELETE /user/1/friend/2
157    sub (DELETE + /user/*/friend/*) {
158      my ($self, $user_id, $friend_id) = @_;
159      ...
160    },
161    # matches: PUT /user/1?first_name=Matt&last_name=Trout
162    sub (PUT + /user/* + ?first_name~&last_name~) {
163      my ($self, $user_id, $first_name, $last_name) = @_;
164      ...
165    },
166    sub (/user/*/...) {
167      my $user_id = $_[1];
168      # matches: PUT /user/1/role/1
169      sub (PUT + /role/*) {
170        my $role_id = $_[1];
171        ...
172      },
173      # matches: DELETE /user/1/role/1
174      sub (DELETE + /role/*) {
175        my $role_id = $_[1];
176        ...
177      },
178    },
179  }
180
181 =head2 The dispatch cycle
182
183 At the beginning of a request, your app's dispatch_request method is called
184 with the PSGI $env as an argument. You can handle the request entirely in
185 here and return a PSGI response arrayref if you want:
186
187   sub dispatch_request {
188     my ($self, $env) = @_;
189     [ 404, [ 'Content-type' => 'text/plain' ], [ 'Amnesia == fail' ] ]
190   }
191
192 However, generally, instead of that, you return a set of dispatch subs:
193
194   sub dispatch_request {
195     my $self = shift;
196     sub (/) { redispatch_to '/index.html' },
197     sub (/user/*) { $self->show_user($_[1]) },
198     ...
199   }
200
201 Well, a sub is a valid PSGI response too (for ultimate streaming and async
202 cleverness). If you want to return a PSGI sub you have to wrap it into an
203 array ref.
204
205   sub dispatch_request {
206     [ sub { 
207         my $respond = shift;
208         # This is pure PSGI here, so read perldoc PSGI
209     } ]
210   }
211
212 If you return a subroutine with a prototype, the prototype is treated
213 as a match specification - and if the test is passed, the body of the
214 sub is called as a method any matched arguments (see below for more details).
215
216 You can also return a plain subroutine which will be called with just $env
217 - remember that in this case if you need $self you -must- close over it.
218
219 If you return a normal object, L<Web::Simple> will simply return it upwards on
220 the assumption that a response_filter (or some arbitrary L<Plack::Middleware>)
221 somewhere will convert it to something useful.  This allows:
222
223   sub dispatch_request {
224     my $self = shift;
225     sub (.html) { response_filter { $self->render_zoom($_[0]) } },
226     sub (/user/*) { $self->users->get($_[1]) },
227   }
228
229 to render a user object to HTML, if there is an incoming URL such as:
230
231   http://myweb.org/user/111.html
232
233 This works because as we descend down the dispachers, we first match
234 C<sub (.html)>, which adds a C<response_filter> (basically a specialized routine
235 that follows the L<Plack::Middleware> specification), and then later we also
236 match C<sub (/user/*)> which gets a user and returns that as the response.
237 This user object 'bubbles up' through all the wrapping middleware until it hits
238 the C<response_filter> we defined, after which the return is converted to a
239 true html response.
240
241 However, two types of object are treated specially - a Plack::App object
242 will have its C<->to_app> method called and be used as a dispatcher:
243
244   sub dispatch_request {
245     my $self = shift;
246     sub (/static/...) { Plack::App::File->new(...) },
247     ...
248   }
249
250 A Plack::Middleware object will be used as a filter for the rest of the
251 dispatch being returned into:
252
253   ## responds to /admin/track_usage AND /admin/delete_accounts
254
255   sub dispatch_request {
256     my $self = shift;
257     sub (/admin/**) {
258       Plack::Middleware::Session->new(%opts);
259     },
260     sub (/admin/track_usage) {
261       ## something that needs a session
262     },
263     sub (/admin/delete_accounts) {
264       ## something else that needs a session
265     },
266   }
267
268 Note that this is for the dispatch being -returned- to, so if you want to
269 provide it inline you need to do:
270
271   ## ALSO responds to /admin/track_usage AND /admin/delete_accounts
272
273   sub dispatch_request {
274     my $self = shift;
275     sub (/admin/...) {
276       sub {
277         Plack::Middleware::Session->new(%opts);
278       },
279       sub (/track_usage) {
280         ## something that needs a session
281       },
282       sub (/delete_accounts) {
283         ## something else that needs a session
284       },
285     }
286   }
287
288 And that's it - but remember that all this happens recursively - it's
289 dispatchers all the way down.  A URL incoming pattern will run all matching
290 dispatchers and then hit all added filters or L<Plack::Middleware>.
291
292 =head2 Web::Simple match specifications
293
294 =head3 Method matches
295
296   sub (GET) {
297
298 A match specification beginning with a capital letter matches HTTP requests
299 with that request method.
300
301 =head3 Path matches
302
303   sub (/login) {
304
305 A match specification beginning with a / is a path match. In the simplest
306 case it matches a specific path. To match a path with a wildcard part, you
307 can do:
308
309   sub (/user/*) {
310     $self->handle_user($_[1])
311
312 This will match /user/<anything> where <anything> does not include a literal
313 / character. The matched part becomes part of the match arguments. You can
314 also match more than one part:
315
316   sub (/user/*/*) {
317     my ($self, $user_1, $user_2) = @_;
318
319   sub (/domain/*/user/*) {
320     my ($self, $domain, $user) = @_;
321
322 and so on. To match an arbitrary number of parts, use -
323
324   sub (/page/**) {
325     my ($self, $match) = @_;
326
327 This will result in a single element for the entire match. Note that you can do
328
329   sub (/page/**/edit) {
330
331 to match an arbitrary number of parts up to but not including some final
332 part.
333
334 Note: Since Web::Simple handles a concept of file extensions, * and **
335 matchers will not by default match things after a final dot, and this
336 can be modified by using *.* and **.* in the final position, i.e.:
337
338   /one/*       matches /one/two.three    and captures "two"
339   /one/*.*     matches /one/two.three    and captures "two.three"
340   /**          matches /one/two.three    and captures "one/two"
341   /**.*        matches /one/two.three    and captures "one/two.three"
342
343 Finally,
344
345   sub (/foo/...) {
346
347 Will match C</foo/> on the beginning of the path -and- strip it. This is
348 designed to be used to construct nested dispatch structures, but can also prove
349 useful for having e.g. an optional language specification at the start of a
350 path.
351
352 Note that the '...' is a "maybe something here, maybe not" so the above
353 specification will match like this:
354
355   /foo         # no match
356   /foo/        # match and strip path to '/'
357   /foo/bar/baz # match and strip path to '/bar/baz'
358
359 Almost the same,
360
361   sub (/foo...) {
362
363 Will match on C</foo/bar/baz>, but also include C</foo>.  Otherwise it
364 operates the same way as C</foo/...>.
365
366   /foo         # match and strip path to ''
367   /foo/        # match and strip path to '/'
368   /foo/bar/baz # match and strip path to '/bar/baz'
369
370 Please note the difference between C<sub(/foo/...)> and C<sub(/foo...)>.  In
371 the first case, this is expecting to find something after C</foo> (and fails to
372 match if nothing is found), while in the second case we can match both C</foo>
373 and C</foo/more/to/come>.  The following are roughly the same:
374
375   sub (/foo)   { 'I match /foo' },
376   sub (/foo/...) {
377     sub (/bar) { 'I match /foo/bar' },
378     sub (/*)   { 'I match /foo/{id}' },
379   }
380
381 Versus
382
383   sub (/foo...) {
384     sub (~)    { 'I match /foo' },
385     sub (/bar) { 'I match /foo/bar' },
386     sub (/*)   { 'I match /foo/{id}' },
387   }
388
389 You may prefer the latter example should you wish to take advantage of
390 subdispatchers to scope common activities.  For example:
391
392   sub (/user...) {
393     my $user_rs = $schema->resultset('User');
394     sub (~) { $user_rs },
395     sub (/*) { $user_rs->find($_[1]) },
396   }
397
398 You should note the special case path match C<sub (~)> which is only meaningful
399 when it is contained in this type of path match. It matches to an empty path.
400
401 =head4 C</foo> and C</foo/> are different specs
402
403 As you may have noticed with the difference between C<sub(/foo/...)> and
404 C<sub(/foo...)>, trailing slashes in path specs are significant. This is
405 intentional and necessary to retain the ability to use relative links on
406 websites. Let's demonstrate on this link:
407
408   <a href="bar">bar</a>
409
410 If the user loads the url C</foo/> and clicks on this link, they will be
411 sent to C</foo/bar>. However when they are on the url C</foo> and click this
412 link, then they will be sent to C</bar>.
413
414 This makes it necessary to be explicit about the trailing slash.
415
416 =head3 Extension matches
417
418   sub (.html) {
419
420 will match .html from the path (assuming the subroutine itself returns
421 something, of course). This is normally used for rendering - e.g.
422
423   sub (.html) {
424     response_filter { $self->render_html($_[1]) }
425   }
426
427 Additionally,
428
429   sub (.*) {
430
431 will match any extension and supplies the extension as a match argument.
432
433 =head3 Query and body parameter matches
434
435 Query and body parameters can be match via
436
437   sub (?<param spec>) { # match URI query
438   sub (%<param spec>) { # match body params
439
440 The body spec will match if the request content is either
441 application/x-www-form-urlencoded or multipart/form-data - the latter
442 of which is required for uploads, which are now handled experimentally
443 - see below.
444
445 The param spec is elements of one of the following forms -
446
447   param~        # optional parameter
448   param=        # required parameter
449   @param~       # optional multiple parameter
450   @param=       # required multiple parameter
451   :param~       # optional parameter in hashref
452   :param=       # required parameter in hashref
453   :@param~      # optional multiple in hashref
454   :@param=      # required multiple in hashref
455   *             # include all other parameters in hashref
456   @*            # include all other parameters as multiple in hashref
457
458 separated by the & character. The arguments added to the request are
459 one per non-:/* parameter (scalar for normal, arrayref for multiple),
460 plus if any :/* specs exist a hashref containing those values.
461
462 Please note that if you specify a multiple type parameter match, you are
463 ensured of getting an arrayref for the value, EVEN if the current incoming
464 request has only one value.  However if a parameter is specified as single
465 and multiple values are found, the last one will be used.
466
467 For example to match a page parameter with an optional order_by parameter one
468 would write:
469
470   sub (?page=&order_by~) {
471     my ($self, $page, $order_by) = @_;
472     return unless $page =~ /^\d+$/;
473     $page ||= 'id';
474     response_filter {
475       $_[1]->search_rs({}, $p);
476     }
477   }
478
479 to implement paging and ordering against a L<DBIx::Class::ResultSet> object.
480
481 Another Example: To get all parameters as a hashref of arrayrefs, write:
482
483   sub(?@*) {
484     my ($self, $params) = @_;
485     ...
486
487 To get two parameters as a hashref, write:
488
489   sub(?:user~&:domain~) {
490     my ($self, $params) = @_; # params contains only 'user' and 'domain' keys
491
492 You can also mix these, so:
493
494   sub (?foo=&@bar~&:coffee=&@*) {
495      my ($self, $foo, $bar, $params);
496
497 where $bar is an arrayref (possibly an empty one), and $params contains
498 arrayref values for all parameters -not- mentioned and a scalar value for
499 the 'coffee' parameter.
500
501 Note, in the case where you combine arrayref, single parameter and named
502 hashref style, the arrayref and single parameters will appear in C<@_> in the
503 order you defined them in the protoype, but all hashrefs will merge into a
504 single C<$params>, as in the example above.
505
506 =head3 Upload matches (EXPERIMENTAL)
507
508 Note: This feature is experimental. This means that it may not remain
509 100% in its current form. If we change it, notes on updating your code
510 will be added to the L</CHANGES BETWEEN RELEASES> section below.
511
512   sub (*foo=) { # param specifier can be anything valid for query or body
513
514 The upload match system functions exactly like a query/body match, except
515 that the values returned (if any) are C<Web::Dispatch::Upload> objects.
516
517 Note that this match type will succeed in two circumstances where you might
518 not expect it to - first, when the field exists but is not an upload field
519 and second, when the field exists but the form is not an upload form (i.e.
520 content type "application/x-www-form-urlencoded" rather than
521 "multipart/form-data"). In either of these cases, what you'll get back is
522 a C<Web::Dispatch::NotAnUpload> object, which will C<die> with an error
523 pointing out the problem if you try and use it. To be sure you have a real
524 upload object, call
525
526   $upload->is_upload # returns 1 on a valid upload, 0 on a non-upload field
527
528 and to get the reason why such an object is not an upload, call
529
530   $upload->reason # returns a reason or '' on a valid upload.
531
532 Other than these two methods, the upload object provides the same interface
533 as L<Plack::Request::Upload> with the addition of a stringify to the temporary
534 filename to make copying it somewhere else easier to handle.
535
536 =head3 Combining matches
537
538 Matches may be combined with the + character - e.g.
539
540   sub (GET + /user/*) {
541
542 to create an AND match. They may also be combined withe the | character - e.g.
543
544   sub (GET|POST) {
545
546 to create an OR match. Matches can be nested with () - e.g.
547
548   sub ((GET|POST) + /user/*) {
549
550 and negated with ! - e.g.
551
552   sub (!/user/foo + /user/*) {
553
554 ! binds to the immediate rightmost match specification, so if you want
555 to negate a combination you will need to use
556
557   sub ( !(POST|PUT|DELETE) ) {
558
559 and | binds tighter than +, so
560
561   sub ((GET|POST) + /user/*) {
562
563 and
564
565   sub (GET|POST + /user/*) {
566
567 are equivalent, but
568
569   sub ((GET + /admin/...) | (POST + /admin/...)) {
570
571 and
572
573   sub (GET + /admin/... | POST + /admin/...) {
574
575 are not - the latter is equivalent to
576
577   sub (GET + (/admin/...|POST) + /admin/...) {
578
579 which will never match!
580
581 =head3 Whitespace
582
583 Note that for legibility you are permitted to use whitespace -
584
585   sub (GET + /user/*) {
586
587 but it will be ignored. This is because the perl parser strips whitespace
588 from subroutine prototypes, so this is equivalent to
589
590   sub (GET+/user/*) {
591
592 =head3 Accessing the PSGI env hash
593
594 In some cases you may wish to get the raw PSGI env hash - to do this,
595 you can either use a plain sub -
596
597   sub {
598     my ($env) = @_;
599     ...
600   }
601
602 or use the PSGI_ENV constant exported to retrieve it:
603
604   sub (GET + /foo + ?some_param=) {
605     my $param = $_[1];
606     my $env = $_[PSGI_ENV];
607   }
608
609 but note that if you're trying to add a middleware, you should simply use
610 Web::Simple's direct support for doing so.
611
612 =head1 EXPORTED SUBROUTINES
613
614 =head2 response_filter
615
616   response_filter {
617     # Hide errors from the user because we hates them, preciousss
618     if (ref($_[0]) eq 'ARRAY' && $_[0]->[0] == 500) {
619       $_[0] = [ 200, @{$_[0]}[1..$#{$_[0]}] ];
620     }
621     return $_[0];
622   };
623
624 The response_filter subroutine is designed for use inside dispatch subroutines.
625
626 It creates and returns a special dispatcher that always matches, and calls
627 the block passed to it as a filter on the result of running the rest of the
628 current dispatch chain.
629
630 Thus the filter above runs further dispatch as normal, but if the result of
631 dispatch is a 500 (Internal Server Error) response, changes this to a 200 (OK)
632 response without altering the headers or body.
633
634 =head2 redispatch_to
635
636   redispatch_to '/other/url';
637
638 The redispatch_to subroutine is designed for use inside dispatch subroutines.
639
640 It creates and returns a special dispatcher that always matches, and instead
641 of continuing dispatch re-delegates it to the start of the dispatch process,
642 but with the path of the request altered to the supplied URL.
643
644 Thus if you receive a POST to '/some/url' and return a redispatch to
645 '/other/url', the dispatch behaviour will be exactly as if the same POST
646 request had been made to '/other/url' instead.
647
648 Note, this is not the same as returning an HTTP 3xx redirect as a response;
649 rather it is a much more efficient internal process.
650
651 =head1 CHANGES BETWEEN RELEASES
652
653 =head2 Changes between 0.004 and 0.005
654
655 =over 4
656
657 =item * dispatch {} replaced by declaring a dispatch_request method
658
659 dispatch {} has gone away - instead, you write:
660
661   sub dispatch_request {
662     my $self = shift;
663     sub (GET /foo/) { ... },
664     ...
665   }
666
667 Note that this method is still -returning- the dispatch code - just like
668 dispatch did.
669
670 Also note that you need the 'my $self = shift' since the magic $self
671 variable went away.
672
673 =item * the magic $self variable went away.
674
675 Just add 'my $self = shift;' while writing your 'sub dispatch_request {'
676 like a normal perl method.
677
678 =item * subdispatch deleted - all dispatchers can now subdispatch
679
680 In earlier releases you needed to write:
681
682   subdispatch sub (/foo/...) {
683     ...
684     [
685       sub (GET /bar/) { ... },
686       ...
687     ]
688   }
689
690 As of 0.005, you can instead write simply:
691
692   sub (/foo/...) {
693     ...
694     (
695       sub (GET /bar/) { ... },
696       ...
697     )
698   }
699
700 =back
701
702 =head2 Changes since Antiquated Perl
703
704 =over 4
705
706 =item * filter_response renamed to response_filter
707
708 This is a pure rename; a global search and replace should fix it.
709
710 =item * dispatch [] changed to dispatch {}
711
712 Simply changing
713
714   dispatch [ sub(...) { ... }, ... ];
715
716 to
717
718   dispatch { sub(...) { ... }, ... };
719
720 should work fine.
721
722 =back
723
724 =head1 DEVELOPMENT HISTORY
725
726 Web::Simple was originally written to form part of my Antiquated Perl talk for
727 Italian Perl Workshop 2009, but in writing the bloggery example I realised
728 that having a bare minimum system for writing web applications that doesn't
729 drive me insane was rather nice and decided to spend my attempt at nanowrimo
730 for 2009 improving and documenting it to the point where others could use it.
731
732 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
733 L<Web::Simple::AntiquatedPerl>.
734
735 =head1 COMMUNITY AND SUPPORT
736
737 =head2 IRC channel
738
739 irc.perl.org #web-simple
740
741 =head2 No mailing list yet
742
743 Because mst's non-work email is a bombsite so he'd never read it anyway.
744
745 =head2 Git repository
746
747 Gitweb is on http://git.shadowcat.co.uk/ and the clone URL is:
748
749   git clone git://git.shadowcat.co.uk/catagits/Web-Simple.git
750
751 =head1 AUTHOR
752
753 Matt S. Trout (mst) <mst@shadowcat.co.uk>
754
755 =head1 CONTRIBUTORS
756
757 Devin Austin (dhoss) <dhoss@cpan.org>
758
759 Arthur Axel 'fREW' Schmidt <frioux@gmail.com>
760
761 gregor herrmann (gregoa) <gregoa@debian.org>
762
763 John Napiorkowski (jnap) <jjn1056@yahoo.com>
764
765 Josh McMichael <jmcmicha@linus222.gsc.wustl.edu>
766
767 Justin Hunter (arcanez) <justin.d.hunter@gmail.com>
768
769 Kjetil Kjernsmo <kjetil@kjernsmo.net>
770
771 markie <markie@nulletch64.dreamhost.com>
772
773 Christian Walde (Mithaldu) <walde.christian@googlemail.com>
774
775 nperez <nperez@cpan.org>
776
777 Robin Edwards <robin.ge@gmail.com>
778
779 Andrew Rodland (hobbs) <andrew@cleverdomain.org>
780
781 =head1 COPYRIGHT
782
783 Copyright (c) 2011 the Web::Simple L</AUTHOR> and L</CONTRIBUTORS>
784 as listed above.
785
786 =head1 LICENSE
787
788 This library is free software and may be distributed under the same terms
789 as perl itself.
790
791 =cut
792
793 1;