NAME

Egg::Helper::Plugin::Maker - Helper who generates plug-in module.

SYNOPSIS

The plugin module is generated in the helper script of the project.

  % perl myapp_helper.pl NewPlugin -v 1.00
  
  % ls /path/to/myapp
  ...
  .....
  drwxr-xr-x ..... Egg-Plugin-NewPlugin

An arbitrary perl module is generated.

  % perl /path/to/egg_makemaker.pl MyModules::Tools
  
  % ls
  ...
  .....
  drwxr-xr-x ..... MyModules-Tools

DESCRIPTION

It is a helper who generates the skeleton of the plugin module.

Can it not be caught in the plugin and the skeleton of an arbitrary Perl module be generated by obtaining the module generation script.

Generation is done when starting from the helper script by the name that continues the plugin name specified behind Egg::Plugin.

Moreover, the generation place is sure to become the route of the project. In a word, '-o' option is disregarded.

Generation is done as it is when starting from the module generation script by the specified name.

The output destination can be specified by '-o' option and output to the current directory when omitting it.

METHODS

out

The module generation script is output to STDOUT.

Please do as follows and develop with the file.

  % perl -MEgg::Helper::Plugin::Maker \
       -e "Egg::Helper::Plugin::Maker-out" > /path/to/egg_makemaker.pl

* It might be convenient to grant the execution permission arbitrarily.

MAKING GUIDE of PLUGIN

It is information that becomes the hint of making the plugin.

About the dispatching priority of the plugin

Egg operates @ISA as succeeded to to the project that does include. At this time, the loaded each plug-in is sequentially added to @ISA, and Egg is added at the end.

Therefore, dispatching priority is as follows.

  1. Controller of project.
  2. Order by which plugin is loaded.
  3. Egg.

And, each method call from Egg executes the module of the @ISA registration by Class::C3 going it.

For instance, if it wants to put interrupt by the scene that Egg calls the method of '_prepare', it is described that the method of '_prepare' is prepared in the made plug-in, necessary processing is made, and processing is passed to the following module.

  sub _prepare {
    my($e)= @_;
    .... ban, ba, ba, ban.
    $e->next::method;
  }

* The call ends by the module if it forgets to describe $e->next::method.

About the call of each method of Egg.

The method call is being written in the document of Egg, and refer to that, please.

  • _setup

    It is a call for the setup when processing begins.

    It moves only once at the start when operating as a perpetuity object such as mod_perl and FastCGI. Therefore, when it uses it for no efficiency code, checking the configuration, and operating every time are effective.

      sub _setup {
        my($e)= @_;
        my $conf= $e->config->{plugin_orign} ||= {};
        $conf->{foo} ||= 'default';
        $e->next::method;
      }
  • _prepare

    It is the first call called after the object of the project is generated.

    It might be good to write the code related to a prior preparation beforehand when it is preferable to generate the object etc.

      sub _prepare {
        my($e)= @_;
        $e->my_accessor( MyPlugin::handler->new($e) );
        $e->next::method;
      }
  • _dispatch_start

    It is originally a call of dispatch to process the first movement.

    Wanting to process it from which plugin by '_prepare' at the end are more certain to put interrupt here.

      sub _dispatch_start
        my($e)= @_;
        ... delay code.
        $e->next::method;
      }
  • _dispatch_action

    It is originally a call to execute the action matched with dispatch.

    I think processing by the behavior situation of dispatch in '_dispatch_start' might become a done code.

      sub _dispatch_action {
        my($e)= @_;
        ... ban, bo, bo, bon.
        $e->next::method;
      }
  • _dispatch_finish

    It is originally a call to process dispatch after the fact.

    It is more certain to put interrupt on here when there is processing that wants to do earlier than the plugin that operates by the following '_finalize'.

      sub _dispatch_finish {
        my($e)= $e->next::method;
        ... ban, bo, bo, bon.
        $e;
      }
  • _finalize

    It is a call for the processing that wants to do before outputting contents.

      sub _finalize {
        my($e)= @_;
        ... finalize code.
        $e->next::method;
      }
  • _finalize_output

    It is originally a call to output contents.

    It is more certain to put interrupt on here to process it from which plug-in that operates by '_finalize' at the end.

      sub _finalize_output {
        my($e)= @_;
        ... finalize code.
        $e->next::method;
      }

    After contents are output when making it as follows, it will process it.

      sub _finalize_output {
        my($e)= $e->next::method;
        ... finalize code.
        $e;
      }
  • _finalize_error

    When the error occurs, it is called.

      sub _finalize_error {
        my($e)= @_;
        ... finalize code.
        $e->next::method;
      }

    After the error screen is output when making it as follows, it will process it.

      sub _finalize_error {
        my($e)= $e->next::method;
        ... finalize code.
        $e;
      }
  • _finalize_result

    It is originally a call to return the result code after contents are output.

    Perhaps, even whenever the error occurs, it is called.

    Please put interrupt on here only when there is processing that wants to do at the end by all means.

    However, the error here is fatal because it has already come off the error trap.

SEE ALSO

Egg::Helper, Egg::Release,

AUTHOR

Masatoshi Mizuno <lushe@cpan.org>

COPYRIGHT

Copyright (C) 2007 by Bee Flag, Corp. <http://egg.bomcity.com/>, All Rights Reserved.

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