X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FWeb%2FSimple.pm;h=a334187e76928d961ecf1833a10ee4e380dbf8bd;hb=20645c5fa990200aa5e75011113659c4513c4c50;hp=4952730ee3dc977bb2d14b0883ff363f153079d0;hpb=950d88296fd5e69f70aac5cf049fc0b9648c3ed3;p=catagits%2FWeb-Simple.git diff --git a/lib/Web/Simple.pm b/lib/Web/Simple.pm index 4952730..a334187 100644 --- a/lib/Web/Simple.pm +++ b/lib/Web/Simple.pm @@ -3,13 +3,17 @@ package Web::Simple; use strictures 1; use 5.008; use warnings::illegalproto (); +use Moo (); +use Web::Dispatch::Wrapper (); -our $VERSION = '0.004'; +our $VERSION = '0.020'; sub import { my ($class, $app_package) = @_; - $class->_export_into($app_package||caller); - eval "package $class; use Web::Dispatch::Wrapper; use Moo;"; + $app_package ||= caller; + $class->_export_into($app_package); + eval "package $app_package; use Web::Dispatch::Wrapper; use Moo; 1" + or die "Failed to setup app package: $@"; strictures->import; warnings::illegalproto->unimport; } @@ -26,92 +30,81 @@ 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 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/perl - - use Web::Simple 'HelloWorld'; + #!/usr/bin/env perl - { - 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' ] ] } } HelloWorld->run_if_script; -If you save this file into your cgi-bin as hello-world.cgi and then visit +If you save this file into your cgi-bin as C 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 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. -=head1 WHY? +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. -Web::Simple was originally written to form part of my Antiquated Perl talk for -Italian Perl Workshop 2009, but in writing the bloggery example I realised -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. +For more complex examples and non-CGI deployment, see +L. To get help with L, please connect to +the irc.perl.org IRC network and join #web-simple. + +=head1 DESCRIPTION -The philosophy of Web::Simple is to keep to an absolute bare minimum, for +The philosophy of L is to keep to an absolute bare minimum for everything. It is not designed to be used for large scale applications; the L web framework already works very nicely for that and is a far more mature, well supported piece of software. However, if you have an application that only does a couple of things, and -want to not have to think about complexities of deployment, then Web::Simple +want to not have to think about complexities of deployment, then L might be just the thing for you. -The Antiquated Perl talk can be found at L. - -=head1 DESCRIPTION - -The only public interface the Web::Simple module itself provides is an -import based one - +The only public interface the L module itself provides is an +C based one: use Web::Simple 'NameOfApplication'; -This imports 'strict' and 'warnings FATAL => "all"' into your code as well, -so you can skip the usual +This sets up your package (in this case "NameOfApplication" is your package) +so that it inherits from L and imports L, +as well as installs a C constant for convenience, as well as some +other subroutines. + +Importing L will automatically make your code use the C and +C pragma, so you can skip the usual: use strict; - use warnings; + 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 that you did 'use Web::Simple' in, then your application will die. This is, so far, considered a feature. -Calling the import also makes NameOfApplication isa Web::Simple::Application -and sets your app class up as a L class- i.e. does the equivalent of +When we inherit from L we also use L, which is +the the equivalent of: { package NameOfApplication; @@ -119,6 +112,10 @@ and sets your app class up as a L class- i.e. does the equivalent of extends 'Web::Simple::Application'; } +So you can use L features in your application, such as creating attributes +using the C subroutine, etc. Please see the documentation for L for +more information. + It also exports the following subroutines for use in dispatchers: response_filter { ... }; @@ -135,8 +132,24 @@ 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 despite being straightforward to use, has a powerful system +for matching all sorts of incoming URLs to one or more subroutines. These +subroutines can be simple actions to take for a given URL, or something +more complicated, including entire L applications, L +and nested subdispatchers. + =head2 Examples sub dispatch_request { @@ -177,78 +190,131 @@ is encountered in other code. }, } -=head2 -Description of the dispatcher object +=head2 The dispatch cycle -Web::Simple::Dispatcher objects have three components: +At the beginning of a request, your app's dispatch_request method is called +with the PSGI $env as an argument. You can handle the request entirely in +here and return a PSGI response arrayref if you want: -=over 4 + sub dispatch_request { + my ($self, $env) = @_; + [ 404, [ 'Content-type' => 'text/plain' ], [ 'Amnesia == fail' ] ] + } -=item * match - an optional test if this dispatcher matches the request +However, generally, instead of that, you return a set of dispatch subs: -=item * call - a routine to call if this dispatcher matches (or has no match) + sub dispatch_request { + my $self = shift; + sub (/) { redispatch_to '/index.html' }, + sub (/user/*) { $self->show_user($_[1]) }, + ... + } -=item * next - the next dispatcher to call +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. -=back + 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 and passed any matched arguments (see below for more details). + +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 close over it. -When a dispatcher is invoked, it checks its match routine against the -request environment. The match routine may provide alterations to the -request as a result of matching, and/or arguments for the call routine. +If you return a normal object, L will simply return it upwards on +the assumption that a response_filter (or some arbitrary L) +somewhere will convert it to something useful. This allows: -If no match routine has been provided then Web::Simple treats this as -a success, and supplies the request environment to the call routine as -an argument. + sub dispatch_request { + my $self = shift; + sub (.html) { response_filter { $self->render_zoom($_[0]) } }, + sub (/user/*) { $self->users->get($_[1]) }, + } -Given a successful match, the call routine is now invoked in list context -with any arguments given to the original dispatch, plus any arguments -provided by the match result. +An alternative to using prototypes to declare a match specification for a given +route is to provide a Dancer like key-value list: -If this routine returns (), Web::Simple treats this identically to a failure -to match. + sub dispatch_request { + my $self = shift; + ( + '.html' => sub { response_filter { $self->render_zoom($_[0]) } }, + '/user/*' => sub { $self->users->get($_[1]) }< + ) + } -If this routine returns a Web::Simple::Dispatcher, the environment changes -are merged into the environment and the new dispatcher's next pointer is -set to our next pointer. +This can be useful in situations where you are generating a dispatch table +programmatically, where setting a subroutines protoype is difficult. -If this routine returns anything else, that is treated as the end of dispatch -and the value is returned. +to render a user object to HTML, if there is an incoming URL such as: -On a failed match, Web::Simple invokes the next dispatcher with the same -arguments and request environment passed to the current one. On a successful -match that returned a new dispatcher, Web::Simple invokes the new dispatcher -with the same arguments but the modified request environment. + http://myweb.org/user/111.html -=head2 How Web::Simple builds dispatcher objects for you +This works because as we descend down the dispachers, we first match +C, which adds a C (basically a specialized routine +that follows the L specification), and then later we also +match C which gets a user and returns that as the response. +This user object 'bubbles up' through all the wrapping middleware until it hits +the C we defined, after which the return is converted to a +true html response. -In the case of the Web::Simple L export the match is constructed -from the subroutine prototype - i.e. +However, two types of object are treated specially - a C object +will have its C method called and be used as a dispatcher: - sub () { - + sub dispatch_request { + my $self = shift; + sub (/static/...) { Plack::App::File->new(...) }, + ... } -and the 'next' pointer is populated with the next element of the array, -expect for the last element, which is given a next that will throw a 500 -error if none of your dispatchers match. If you want to provide something -else as a default, a routine with no match specification always matches, so - +A L 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 - sub () { - [ 404, [ 'Content-type', 'text/plain' ], [ 'Error: Not Found' ] ] + sub dispatch_request { + my $self = shift; + sub (/admin/**) { + Plack::Middleware::Session->new(%opts); + }, + sub (/admin/track_usage) { + ## something that needs a session + }, + sub (/admin/delete_accounts) { + ## something else that needs a session + }, } -will produce a 404 result instead of a 500 by default. You can also override -the L method in your app. +Note that this is for the dispatch being B to, so if you want to +provide it inline you need to do: -Note that the code in the subroutine is executed as a -method- on your -application object, so if your match specification provides arguments you -should unpack them like so: + ## ALSO responds to /admin/track_usage AND /admin/delete_accounts - sub () { - my ($self, @args) = @_; - ... + sub dispatch_request { + my $self = shift; + sub (/admin/...) { + sub { + Plack::Middleware::Session->new(%opts); + }, + sub (/track_usage) { + ## something that needs a session + }, + sub (/delete_accounts) { + ## something else that needs a session + }, + } } +And that's it - but remember that all this happens recursively - it's +dispatchers all the way down. A URL incoming pattern will run all matching +dispatchers and then hit all added filters or L. + =head2 Web::Simple match specifications =head3 Method matches @@ -279,26 +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, much like -.html strips the extension. 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 on the beginning of the path B 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: @@ -307,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, but also include C. Otherwise it +operates the same way as C. + + /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 and C. In +the first case, this is expecting to find something after C (and fails to +match if nothing is found), while in the second case we can match both C +and C. 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 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 and C are different specs + +As you may have noticed with the difference between C and +C, 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: + + bar + +If the user loads the url C and clicks on this link, they will be +sent to C. However when they are on the url C and click this +link, then they will be sent to C. + +This makes it necessary to be explicit about the trailing slash. + =head3 Extension matches sub (.html) { -will match and strip .html from the path (assuming the subroutine itself -returns something, of course). This is normally used for rendering - e.g. +will match .html from the path (assuming the subroutine itself returns +something, of course). This is normally used for rendering - e.g.: sub (.html) { response_filter { $self->render_html($_[1]) } @@ -322,8 +474,7 @@ Additionally, sub (.*) { -will match any extension and supplies the stripped extension as a match -argument. +will match any extension and supplies the extension as a match argument. =head3 Query and body parameter matches @@ -332,11 +483,11 @@ Query and body parameters can be match via sub (?) { # match URI query sub (%) { # 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 @@ -349,11 +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. -So, to match a page parameter with an optional order_by parameter one +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 C parameter with an optional C parameter one would write: sub (?page=&order_by~) { @@ -367,10 +523,7 @@ would write: to implement paging and ordering against a L object. -Note that if a parameter is specified as single and multiple values are found, -the last one will be used. - -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) = @_; @@ -387,9 +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 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 +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 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 object, which will C 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 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. @@ -423,21 +607,21 @@ and are equivalent, but - sub ((GET + .html) | (POST + .html)) { + sub ((GET + /admin/...) | (POST + /admin/...)) { and - sub (GET + .html | POST + .html) { + sub (GET + /admin/... | POST + /admin/...) { are not - the latter is equivalent to - sub (GET + (.html|POST) + .html) { + sub (GET + (/admin/...|POST) + /admin/...) { -which will never match. +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/*) { @@ -446,19 +630,64 @@ 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 -To gain the benefit of using some middleware, specifically -Plack::Middleware::Session access to the ENV hash is needed. This is provided -in arguments to the dispatched handler. You can access this hash with the -exported PSGI_ENV constant. +In some cases you may wish to get the raw PSGI env hash - to do this, +you can either use a plain sub: + + sub { + my ($env) = @_; + ... + } - sub (GET + /foo + ?some_param=) { - my($self, $some_param, $env) = @_[0, 1, PSGI_ENV]; +or use the C constant exported to retrieve it from C<@_>: -=head2 Dispatcher return values + sub (GET + /foo + ?some_param=) { + my $param = $_[1]; + my $env = $_[PSGI_ENV]; + } -A dispatcher returns one of: +but note that if you're trying to add a middleware, you should simply use +Web::Simple's direct support for doing so. =head1 EXPORTED SUBROUTINES @@ -492,29 +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 and return a redispatch to +C, the dispatch behaviour will be exactly as if the same POST +request had been made to C instead. -=head2 subdispatch - - subdispatch sub (/user/*/) { - my $u = $self->user($_[1]); - [ - sub (GET) { $u }, - sub (DELETE) { $u->delete }, - ] - } - -The subdispatch subroutine is designed for use in dispatcher construction. - -It creates a dispatcher which, if it matches, treats its return value not -as a final value but an arrayref of dispatch specifications such as could -be passed to the dispatch subroutine itself. These are turned into a dispatcher -which is then invoked. Any changes the match makes to the request are in -scope for this inner dispatcher only - so if the initial match is a -destructive one like .html the full path will be restored if the -subdispatch fails. +Note, this is not the same as returning an HTTP 3xx redirect as a response; +rather it is a much more efficient internal process. =head1 CHANGES BETWEEN RELEASES @@ -532,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 the dispatch code - just like +C 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 @@ -565,6 +777,8 @@ As of 0.005, you can instead write simply: ) } +=back + =head2 Changes since Antiquated Perl =over 4 @@ -587,6 +801,17 @@ should work fine. =back +=head1 DEVELOPMENT HISTORY + +Web::Simple was originally written to form part of my Antiquated Perl talk for +Italian Perl Workshop 2009, but in writing the bloggery example I realised +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 and the slides are reproduced in this distribution under +L. + =head1 COMMUNITY AND SUPPORT =head2 IRC channel @@ -605,15 +830,39 @@ Gitweb is on http://git.shadowcat.co.uk/ and the clone URL is: =head1 AUTHOR -Matt S. Trout +Matt S. Trout (mst) =head1 CONTRIBUTORS -None required yet. Maybe this module is perfect (hahahahaha ...). +Devin Austin (dhoss) + +Arthur Axel 'fREW' Schmidt + +gregor herrmann (gregoa) + +John Napiorkowski (jnap) + +Josh McMichael + +Justin Hunter (arcanez) + +Kjetil Kjernsmo + +markie + +Christian Walde (Mithaldu) + +nperez + +Robin Edwards + +Andrew Rodland (hobbs) + +Robert Sedlacek (phaylon) =head1 COPYRIGHT -Copyright (c) 2009 the Web::Simple L and L +Copyright (c) 2011 the Web::Simple L and L as listed above. =head1 LICENSE @@ -622,5 +871,3 @@ This library is free software and may be distributed under the same terms as perl itself. =cut - -1;