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