The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.

NAME

Limper::Extending - how to make Limper more useful

VERSION

version 0.015

DESCRIPTION

Limper is really simple, and meant to have only the features needed. This hopes to show how to extend it and make it more useful in a manageable way.

EXAMPLE

Basic outline of a package that extends Limper:

  package Limper::Plugin::Foo;

  use base 'Limper';
  use 5.10.0;
  use strict;
  use warnings;

  package        # newline because Dist::Zilla::Plugin::PkgVersion and PAUSE indexer
    Limper;

  use Fizz;
  use Buzz;

  push @Limper::EXPORT, qw/foo/;
  push @Limper::EXPORT_OK, qw/bar/;

  hook after => sub { ... }

  sub bar { ... }

  sub foo { ... }

  1;

And then in your app:

  use 5.10.0;
  use strict;
  use warnings;

  use Limper::Plugin::Foo;
  use Limper;   # this must come after all extensions

  get '/foo' => sub { foo };

  limp;

If you also want to be able to send static content, then use Limper::SendFile as well in your app.

NOTE: Using other plugins in your plugin currently may have unintended side-effects if something else wants to use that plugin, too. This should be tested.

LAYOUT

Your plugin should always start with the following, replacing "Foo" with the name of your choice. Limper supports down to 5.10.0 (and will not go lower).

  package Limper::Plugin::Foo;

  use base 'Limper';
  use 5.10.0;
  use strict;
  use warnings;

  package        # newline because Dist::Zilla::Plugin::PkgVersion and PAUSE indexer
    Limper;

All code specific to your plugin follows the above.

NAMESPACES

Modules added to the Limper:: sub-namespaces should be reasonably generic components which are useful as building blocks and not just simply using Limper. See Limper::Passphrase for an example of what should not be a plugin.

If you are writing an interface to connect Limper to a particular web server or protocol, put it under the Limper::Engine:: namespace (like Limper::Engine::PSGI).

If it's an otherwise typical plugin that just creates new fucntions and possibly uses hooks, put it under the Limper::Plugin:: namespace. If your plugin is extending another plugin (with a tight logical relationship, not just requiring it), it should probably be named under that plugin's namespace.

It's not wrong to be polite and mention your plugin's name and purpose to whoever owns the direct parent namespace before publishing (or even creating) it.

There are plugins listed directly under the Limper:: namespace, but please do not name your plugin like this without explicit permission from me. This is reserved for features I deem are core to a robust framework but should not be in Limper proper, or that I maintain, as well as documentation and whatnot. If you feel your plugin really should be named Limper::Foo instead of Limper::Plugin::Foo, contact me (perhaps Limper should have another sub-namespace?). I'm not even sure if Limper::SendFile and Limper::SendJSON should be named as such or moved under Limper::Plugin::.

DO NOT USE the Limper:: namespace to build a new web application or whatnot. It's like naming your application under CGI:: namespace if it's supposed to run on CGI and that is a really bad choice and would confuse people badly.

COPYRIGHT AND LICENSE

Copyright (C) 2014 by Ashley Willis <ashley+perl@gitable.org>

rabcyr on irc and twitter.

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.12.4 or, at your option, any later version of Perl 5 you may have available.

SEE ALSO

Actual examples:

Limper::Engine::PSGI

Limper::SendFile

Limper::SendJSON