view release on metacpan or  search on metacpan

zlib/contrib/pascal/readme.txt  view on Meta::CPAN

  integer.  The Word type is non-portable and has the same size
  (16 bits) both in a 16-bit and in a 32-bit environment, unlike
  Integer.  Even if there is a 32-bit Cardinal type, there is no
  real need for unsigned int in zlib under a 32-bit environment.

- Except for the callbacks, the zlib function interfaces are
  assuming the calling convention normally used in Pascal
  (__pascal for DOS and Windows16, __fastcall for Windows32).
  Since the cdecl keyword is used, the old Turbo Pascal does
  not work with this interface.

 view release on metacpan or  search on metacpan

lib/Business/Stripe/Webhook.pm  view on Meta::CPAN

B<api_secret>: The Stripe secret API Key - see L<https://stripe.com/docs/keys>. Optional but will be required if the C<get_subscription> method is needed.

=item *

B<I<stripe-event>>: One or more callbacks to the subroutines to handle the webhooks events sent by Stripe.  See L<https://stripe.com/docs/api/events/list>.

To listen for an event, change the fullstop in the Stripe event name to a minus sign and use that as the parameter.  The events you define should match the events you ask Stripe to send.  Any events Stripe sends that do not have a callback defined wi...

Stripe event C<invoice.paid> becomes C<invoice-paid>
Stripe event C<invoice.payment_failed> becomes C<invoice-payment_failed>

 view release on metacpan or  search on metacpan

lib/Business/TrueLayer/Request.pm  view on Meta::CPAN

            'Accept'        => 'application/json; charset=UTF-8',
            'Content-Type'  => 'application/json; charset=UTF-8',
            @{ $headers // [] },
        },
        # Mojo::UserAgent::Transactor::tx calls $self->generators and then the
        # callbacks based on the count of @_, and does not expect undef here
        (defined $body ? ($body) : ()),
    ))->result;

    # Easiest to deal with this first, even though it should be very rare:
    if ( $res->code == 301 ) {

 view release on metacpan or  search on metacpan

lib/Business/US_Amort.pm  view on Meta::CPAN

=item interest_rate

The annual rate, expressed like 8.3, not like .083.

Note that if you're defining callbacks, you can change this attribute
at any time in your callbacks, to change the rate of interest from
then on.

=item term

The term of the loan, in years, not months.

lib/Business/US_Amort.pm  view on Meta::CPAN

=back

=head2 ITERATION ATTRIBUTES

These are attributes of little or no interest once C<run> is done, but
may be of interest to callbacks while C<run> is running, or may
be of interest in examining snapshots in C<table>.

=over

=item _month_count

This is how many months we are into the loan.  The first month is 1.

=item _abort

If you want callbacks to be able to halt the iteration for some
reason, you can have them set C<_abort> to true.  You may also choose
to set C<error> to something helpful.

=item _monthly_payment

The amount to be paid to toward the principal each month. At the start
of the loan, this is set to whatever C<initial_monthly_payment> is
figured to be, but you can manipulate C<_monthly_payment> with
callbacks to change how much actually gets paid when.

=item _remainder

The balance on the loan.

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

        Enhancement: built-in logging removes line-breaking whitespace from XML

v0.6.6  2018-02-15
        New: debug and trace logging levels
        New: POSR extrinsic "UserId"
        Enhancement: trap fatal errors occuring during callbacks
        Bugfix: transmissions lost input payloadID since v0.6.5

v0.6.5  2018-02-05
        Bugfix: Transmission.pm: avoid possible conflicts between methods and keys

 view release on metacpan or  search on metacpan

t/samples/rtcpan.rdf  view on Meta::CPAN

<item rdf:about="https://rt.cpan.org/Ticket/Display.html?id=84118">
<title>I really beg you to take back the exception catching feature in Future 0.11</title>
<link>https://rt.cpan.org/Ticket/Display.html?id=84118</link>
<description>I really beg you to take back the new feature in Future 0.11, in which
exceptions are caught by Future in followed_by(), and_then() and
or_else() callbacks.

This is because it can unintensionally hide critical errors and lead
to hard-to-solve bugs.

Suppose I use a function from someone&#x27;s module.

t/samples/rtcpan.rdf  view on Meta::CPAN

<item rdf:about="https://rt.cpan.org/Ticket/Display.html?id=84188">
<title>Error message is not user-friendly for followed_by(), and_then(), or_else() and repeat()</title>
<link>https://rt.cpan.org/Ticket/Display.html?id=84188</link>
<description>I often forget to return a Future in the callback for followed_by(),
and_then() or or_else() method, especially when I just mean to provide
other parts of my program with a way to chain further callbacks.

In this case, the error message should be more user-friendly.

Example:

 view release on metacpan or  search on metacpan

lib/BusyBird/Main/PSGI.pm  view on Meta::CPAN

                $assumed{$query_key} = $query_params->{$query_key};
            }
            my $ret_future = Future::Q->new;
            $timeline->watch_unacked_counts(assumed => \%assumed, callback => sub {
                my ($error, $w, $unacked_counts) = @_;
                $w->cancel(); ## immediately cancel the watcher to prevent multiple callbacks
                if($error) {
                    $ret_future->reject($error, 1);
                }else {
                    $ret_future->fulfill($unacked_counts);
                }

lib/BusyBird/Main/PSGI.pm  view on Meta::CPAN

            }
            my $ret_future = Future::Q->new;
            $self->{main_obj}->watch_unacked_counts(
                level => $level, assumed => \%assumed, callback => sub {
                    my ($error, $w, $tl_unacked_counts) = @_;
                    $w->cancel(); ## immediately cancel the watcher to prevent multiple callbacks
                    if($error) {
                        $ret_future->reject($error, 1);
                    }else {
                        $ret_future->fulfill($tl_unacked_counts);
                    }

 view release on metacpan or  search on metacpan

lib/C/Blocks.xs  view on Meta::CPAN

	SV * msg_SV = get_sv("C::Blocks::_msg", 0);
	sv_setpvn(msg_SV, msg, bytes);
}

/*****************************************/
/**** Extended symbol table callbacks ****/
/*****************************************/

TokenSym_p my_symtab_lookup_by_name(char * name, int len, void * data, extended_symtab_p* containing_symtab) {
	/* Unpack the callback data */
	extended_symtab_callback_data * callback_data = (extended_symtab_callback_data*)data;

lib/C/Blocks.xs  view on Meta::CPAN

	/* Set the extended symbol table lists if they exist */
	if (SvPOK(data->exsymtabs) && SvCUR(data->exsymtabs)) {
		callback_data.N_tables = SvCUR(data->exsymtabs) / sizeof(available_extended_symtab);
		callback_data.available_extended_symtabs = (available_extended_symtab*) SvPV_nolen(data->exsymtabs);
	}
	tcc_set_extended_symtab_callbacks(state, &my_symtab_lookup_by_name,
		&my_symtab_sym_used, &my_prep_table, &callback_data);
	
	/* set the block function's argument, if any */
	if (keyword_type == IS_CBLOCK) {
		/* If this is a block, we need to define C_BLOCKS_THX_DECL.

 view release on metacpan or  search on metacpan

lib/C/DynaLib.pm  view on Meta::CPAN

    ($codeptr, $ret_type, $arg_type, $func)
      = unpack(CONFIG_TEMPLATE, $Config->[$index]);
    last unless $codeptr;
  }
  if ($index > $#{$Config}) {
    carp "Limit of ", scalar(@$Config), " callbacks exceeded";
    return undef;
  }
  ($coderef, $ret_type, @arg_type) = @_;

  $ret_type =~ /^$GoodRet$/o

lib/C/DynaLib.pm  view on Meta::CPAN

Using callback routines

Some C functions expect a pointer to another C function as an
argument.  The library code that receives the pointer may use it to
call an application function at a later time.  Such functions are
called I<callbacks>.

This module allows you to use a Perl sub as a C callback, subject to
certain restrictions.  There is a hard-coded maximum number of
callbacks that can be active at any given time.  The default (4) may
be changed by specifying C<CALLBACKS=number> on the F<Makefile.PL>
command line.

A callback's argument and return types are specified using C<pack>
codes, as described above for library functions.  Currently, the

lib/C/DynaLib.pm  view on Meta::CPAN

  $string2 = "foolish";
  $result = &{$strncmp}($string1, $string2, 3);  # $result is 0
  $result = &{$strncmp}($string1, $string2, 4);  # $result is -1

The files F<test.pl> and F<README.win32> contain examples using
callbacks.

=head1 CALLING CONVENTIONS

This section is intended for anyone who is interested in debugging or
extending this module.  You probably don't need to read it just to

lib/C/DynaLib.pm  view on Meta::CPAN

  &$strncmp($dummy1 = "foo", $dummy2 = "bar", 3);

=head2 Callbacks

Only a certain number of callbacks can exist at a time.  Callbacks can
mess up the message produced by C<die> in the presence of nested
C<eval>s.  The Callback code uses global data, and is consequently not
thread-safe.

=head2 Miscellaneous Bugs

 view release on metacpan or  search on metacpan

src/sparse-0.4.4/LICENSE  view on Meta::CPAN

and annotate the resulting parse tree with the semantic meaning (aka
"types") of the sources.  Thus just the act of linking this library into
another program (aka "back-end") does NOT in itself make that back-end
be considered a derivative work of this Original Work. 

However, any modifications, callbacks or other functionality that is
added and run either directly or indirectly by the front-end are to be
considered derived works of this library, and as such fall under the
requirements of this license.

				Linus Torvalds

 view release on metacpan or  search on metacpan

lib/CAD/Drawing/IO/Tk.pm  view on Meta::CPAN

Ultimately, the focus here will likely drift toward supporting perlcad
and enabling use of perlcad from within CAD::Drawing scripts.  However,
the nature of lights-out scripting vs the nature of on-screen drafting
is quite different, so there will be some tricks involved.  Once each
entity has its own class, the ability to install callbacks and the
resolution of notifications should get easier.  But, there will still
be the issue that a debug popup does not know it will appear when the
entities are created, while a drafting viewport does (or does it?)

Possibly, adding a list of tk-id's to each $obj as it is drawn would be

 view release on metacpan or  search on metacpan

lib/CBOR/PP/Decode.pm  view on Meta::CPAN

=head1 TODO

=over

=item * Add tag decode support via callbacks.

=item * Make it faster by removing some of the internal buffer copying.

=back

 view release on metacpan or  search on metacpan

XS.pm  view on Meta::CPAN

First and foremost, your CBOR decoder should be secure, that is, should
not have any buffer overflows or similar bugs that could potentially be
exploited. Obviously, this module should ensure that and I am trying hard
on making that true, but you never know.

=item CBOR::XS can invoke almost arbitrary callbacks during decoding

CBOR::XS supports object serialisation - decoding CBOR can cause calls
to I<any> C<THAW> method in I<any> package that exists in your process
(that is, CBOR::XS will not try to load modules, but any existing C<THAW>
method or function can be called, so they all have to be secure).

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

  and after, respectively, any xmlhttp request.  It was much
  more responsive this way rather than providing a hook into each
  readyState, especially since there is not uniform support for
  the various readyStates in the common browsers.

  Changed the pjx_loading.pl script to use the above callbacks, and
  documented it.

  Switched from prototype to javascript object notation.  This is
  cosmetic, and only changes the way the code looks, not the way it
  functions.

 view release on metacpan or  search on metacpan

lib/CGI/Application/Framework.pm  view on Meta::CPAN

    my %log_options = (
        LOG_DISPATCH_MODULES => \@log_modules,
    );

    if ($log_config->{'format'}) {
        my @callbacks = @{ $log_config->{'options'}{'callbacks'} ||= [] };
        push @callbacks, Log::Dispatch::Config->format_to_cb($log_config->{'format'});
        $log_config->{'options'}{'callbacks'} = \@callbacks;
    }
    if ($log_config->{'options'}) {
        $log_options{'LOG_DISPATCH_OPTIONS'} = $log_config->{'options'};
    }
    if ($log_config->{'append_newline'}) {

 view release on metacpan or  search on metacpan

lib/CGI/Application/Muto.pm  view on Meta::CPAN

    my $self = shift;

    $self->_init_controllers();
    $self->_init_controller_methods();

    #Some callbacks
    $self->add_callback('prerun', \&_fetch_controller_method);
    $self->add_callback('prerun', \&_check_protected_methods);

    return $self->SUPER::run(); #call CGI::App run method

 view release on metacpan or  search on metacpan

t/podspell.t  view on Meta::CPAN

                                    runmode
                                    runmodes
                                    prerun
                                    pre
                                    callback
                                    callbacks
                                    checkbox
                                    desaturating
                                    writeable
                                    detaint
                                    URLs));

 view release on metacpan or  search on metacpan

lib/CGI/Application/Plugin/AbstractCallback.pm  view on Meta::CPAN

1;
__END__

=head1 NAME

CGI::Application::Plugin::AbstractCallback - This is the abstract method for externalizing callbacks

=head1 SYNOPSIS

	package MyApp::Plugin::MyInitCallback;
	

lib/CGI/Application/Plugin/AbstractCallback.pm  view on Meta::CPAN

	
	1;

=head1 DESCRIPTION

This module is the abstract class for externalizing callbacks.
The callback defined in the child class( of this class)  is added in specified hook.

=head1 METHODS

=head2 callback()

 view release on metacpan or  search on metacpan

lib/CGI/Application/Plugin/AnyTemplate.pm  view on Meta::CPAN

The C<load_tmpl> hook is designed to be compatible with the C<load_tmpl>
hook defined by C<CGI::Application> itself.

The C<load_tmpl> hook is called before the template object is created.
Any callbacks that you register to this hook will be called before each
template is loaded.  Register a C<load_tmpl> callback with:

   $self->add_callback('load_tmpl',\&my_load_tmpl);

When the C<load_tmpl> callback is executed it will be passed three

lib/CGI/Application/Plugin/AnyTemplate.pm  view on Meta::CPAN

C<load_tmpl>.

=head2 The template_pre_process and template_post_process hooks

Before the template output is generated, the C<< template_pre_process >>
hook is called.  Any callbacks that you register to this hook will be
called before each template is processed.  Register a
C<template_pre_process> callback as follows:

    $self->add_callback('template_pre_process', \&my_tmpl_pre_process);

Pre-process callbacks will be passed a reference to the C<$template>
object, and can can modify the parameters passed into the template by
using the C<param> method:

    sub my_tmpl_pre_process {
        my ($self, $template) = @_;

lib/CGI/Application/Plugin/AnyTemplate.pm  view on Meta::CPAN

After the template output is generated, the C<template_post_process> hook is called.
You can register a C<template_post_process> callback as follows:

    $self->add_callback('template_post_process', \&my_tmpl_post_process);

Any callbacks that you register to this hook will be called after each
template is processed, and will be passed both a reference to the
template object and a reference to the output generated by the template.
This allows you to modify the output of the template:

    sub my_tmpl_post_process {

 view release on metacpan or  search on metacpan

lib/CGI/Application/Plugin/Authentication.pm  view on Meta::CPAN

=head1 COMPATIBILITY WITH L<CGI::Application::Plugin::ActionDispatch>

The prerun callback has been modified so that it will check for the presence of a prerun mode.
This is for compatibility with L<CGI::Application::Plugin::ActionDispatch>. This
change should be considered experimental. It is necessary to load the ActionDispatch
module so that the two prerun callbacks will be called in the correct order.

=head1 RECOMMENDED USAGE

=over

 view release on metacpan or  search on metacpan

lib/CGI/Application/Plugin/Authorization.pm  view on Meta::CPAN

        warn
            "Calling package is not a CGI::Application module so not setting up the prerun hook.  If you are using \@ISA instead of 'use base', make sure it is in a BEGIN { } block, and make sure these statements appear before the plugin is loaded";
    }
    elsif ( !UNIVERSAL::can( $callpkg, 'add_callback' ) ) {
        warn
            "You are using an older version of CGI::Application that does not support callbacks, so the prerun method can not be registered automatically (Lookup 'CGI::Application CALLBACKS' in the docs for more info)";
    }
    else {
        $callpkg->add_callback( prerun => \&prerun_callback );
    }
}

 view release on metacpan or  search on metacpan

t/1.t  view on Meta::CPAN

}


# CGI::App::Callbacks tests (4.0 hooks)
 SKIP: {
 	my $has_callbacks = $CGI::Application::VERSION >= 4;
 	
 
	skip 'callback hooks require CGI::Application version 4', 2 
	     	unless $has_callbacks;



{	
	my $testname = "install via Callbacks";

 view release on metacpan or  search on metacpan

t/08-get_current_config.t  view on Meta::CPAN

my $webapp = WebApp->new;
$webapp->run;

SKIP: {
    skip "Current CGI::Application doesn't support callbacks", 2 unless $webapp->can('add_callback');
    my $config1 = CGI::Application::Plugin::Config::General->get_current_config;

    ok((ref $config1 eq 'HASH'),     'default config empty at end of request - hashref returned');
    ok((scalar keys %$config1) == 0, 'default config empty at end of request - hashref has no keys');
}

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

          CAP::AutoRunmode (discovered by Shawn Sorichetti)
        - removed TODO, since everything on the list has been done

1.05    October 03, 2005
        - fixed to work with old versions of CGI::Application that don't
          support callbacks

        - now explicitly 'use CGI::Application' to make the registration
          of hooks it possible to register hooks at class load time.

        - added docs describing the difference between this module and

 view release on metacpan or  search on metacpan

lib/CGI/Application/Plugin/HTCompiled.pm  view on Meta::CPAN

using this plugin.

=head2 import()

Will be called when your Module uses L<HTML::Template::Compiled>. Registers
callbacks at the C<init> and the C<load_tmpl> stages. This is how the plugin
mechanism works.

=cut

sub import {

 view release on metacpan or  search on metacpan

lib/CGI/Application/Plugin/HTDot.pm  view on Meta::CPAN

      return $self->SUPER::load_tmpl($tmpl_file, @extra_params);
  }

This plugin honors the C<load_tmpl()> callback.  Any C<load_tmpl()>-based
callbacks you have created will be executed as intended:

=head1 DEFAULT PARAMETERS

By default, this plugin will automatically add a parameter 'c' to your
template that will return your L<CGI::Application> object.  This will allow

 view release on metacpan or  search on metacpan

lib/CGI/Application/Plugin/LogDispatch.pm  view on Meta::CPAN

                } else {
                    my $module = delete $logger->{module};
                    # setup a callback to append a newline if requested
                    if ($logger->{append_newline} || $options->{APPEND_NEWLINE}) {
                        delete $logger->{append_newline} if exists $logger->{append_newline};
                        $logger->{callbacks} = [ $logger->{callbacks} ]
                            if $logger->{callbacks} &&  ref $logger->{callbacks} ne 'ARRAY';
                        push @{ $logger->{callbacks} }, \&_append_newline;
                    }
                    # add the logger to the dispatcher
                    $log->add( $module->new( %$logger ) );
                }
            }

lib/CGI/Application/Plugin/LogDispatch.pm  view on Meta::CPAN

            my %options = (
                                name => 'screen',
                              stderr => 1,
                           min_level => 'debug',
            );
            $options{callbacks} = \&_append_newline if $options->{APPEND_NEWLINE};
            $log->add( Log::Dispatch::Screen->new( %options ) );
        }
        _set_object($frompkg||$self, $log);

        # CAP::DevPopup support

lib/CGI/Application/Plugin/LogDispatch.pm  view on Meta::CPAN

            # Create logger to capture all log entries
            my %options = (
                'name'      => 'DevPopup',
                'min_level' => 'debug',
                'filename'  => File::Spec->devnull(),
                'callbacks' => sub {
                    my %args = @_;
                    push( @{$self->{LOG_DISPATCH_DEVPOPUP_HISTORY}}, [$args{level}, $args{message}] );
                    },
                );
            $log->add( Log::Dispatch::File->new(%options) );

lib/CGI/Application/Plugin/LogDispatch.pm  view on Meta::CPAN

options that will be passed to the L<Log::Dispatch> constructor.  Please see the documentation
for L<Log::Dispatch> for the exact syntax of the parameters.  Surprisingly enough you will usually
not need to use this option, instead look at the LOG_DISPATCH_MODULES option.

 LOG_DISPATCH_OPTIONS => {
      callbacks => sub { my %h = @_; return time().': '.$h{message}; },
 }

=item LOG_DISPATCH_MODULES

This option allows you to specify the Log::Dispatch::* modules that you wish to use to

 view release on metacpan or  search on metacpan

t/00_use_ok.t  view on Meta::CPAN

use strict;
use warnings;

use Ref::Util qw/is_coderef/;

# we could check that we actually add the callbacks ? that is what `use` is
# suposed to do, we opught to test that here!!
#

my $callbacks = [];
sub add_callback { push @$callbacks, +{ name=> $_[1], coderef =>  $_[2] } };

BEGIN {
    use_ok('CGI::Application::Plugin::OpenTracing::DataDog');
    
    cmp_deeply( $callbacks =>
        [
            {
                name    => 'init',
                coderef => code( \&is_coderef ),
            },

t/00_use_ok.t  view on Meta::CPAN

            {
                name    => 'error',
                coderef => code( \&is_coderef ),
            },
        ],
        "Installed expected callbacks, and these are coderefs!"
    );
    
};

done_testing;

 view release on metacpan or  search on metacpan

lib/CGI/Application/Plugin/OpenTracing.pm  view on Meta::CPAN

#
# CGI::Application::Plugin has an interesting design on itself
#
# within this code base there are three sections:
# - import
# - callbacks, as defined by CGI::Application
# - plugin related methods, that deal with the plugin internals
# - tracing specific routines
# - cgi related routines, that just work on the CGI::Application only
#
################################################################################

 view release on metacpan or  search on metacpan

lib/CGI/Application.pm  view on Meta::CPAN

 $app->{__PARAM} = 'foo'; # BAD! Could conflict.
 $app->{'MyPlugin::Module::__PARAM'} = 'foo'; # Good.
 $app->{'MyPlugin::Module'}{__PARAM} = 'foo'; # Good.

=head2 Writing Advanced Plug-ins - Using callbacks

When writing a plug-in, you may want some action to happen automatically at a
particular stage, such as setting up a database connection or initializing a
session. By using these 'callback' methods, you can register a subroutine
to run at a particular phase, accomplishing this goal.

lib/CGI/Application.pm  view on Meta::CPAN

  # the hook and call it.

  # Create a new hook
  $self->new_hook('pretemplate');

  # Then later execute all the callbacks registered at this hook
  $self->call_hook('pretemplate');

B<Callback Methods>

=head3 add_callback()

lib/CGI/Application.pm  view on Meta::CPAN

method.

The callback should be a reference to a subroutine or the name of a
method.

If multiple callbacks are added to the same hook, they will all be
executed one after the other.  The exact order depends on which class
installed each callback, as described below under B<Callback Ordering>.

Callbacks can either be I<object-based> or I<class-based>, depending
upon whether you call C<add_callback> as an object method or a class
method:

	# add object-based callback
	$self->add_callback('teardown', \&callback);

	# add class-based callbacks
	$class->add_callback('teardown', \&callback);
	My::Project->add_callback('teardown', \&callback);

Object-based callbacks are stored in your web application's C<$c>
object; at the end of the request when the C<$c> object goes out of
scope, the callbacks are gone too.

Object-based callbacks are useful for one-time tasks that apply only to
the current running application.  For instance you could install a
C<teardown> callback to trigger a long-running process to execute at the
end of the current request, after all the HTML has been sent to the
browser.

Class-based callbacks survive for the duration of the running Perl
process.  (In a persistent environment such as C<mod_perl> or
C<PersistentPerl>, a single Perl process can serve many web requests.)

Class-based callbacks are useful for plugins to add features to all web
applications.

Another feature of class-based callbacks is that your plugin can create
hooks and add callbacks at any time - even before the web application's
C<$c> object has been initialized.  A good place to do this is in
your plugin's C<import> subroutine:

	package CGI::Application::Plugin::MyPlugin;
	use base 'Exporter';

lib/CGI/Application.pm  view on Meta::CPAN

=head3 new_hook(HOOK)

    $self->new_hook('pretemplate');

The C<new_hook()> method can be used to create a new location for developers to
register callbacks.  It takes one argument, a hook name. The hook location is
created if it does not already exist. A true value is always returned.

For an example, L<CGI::Application::Plugin::TT> adds hooks before and after every
template is processed.

lib/CGI/Application.pm  view on Meta::CPAN

=head3 call_hook(HOOK)

    $self->call_hook('pretemplate', @args);

The C<call_hook> method is used to executed the callbacks that have been registered
at the given hook.  It is used in conjunction with the C<new_hook> method which
allows you to create a new hook location.

The first argument to C<call_hook> is the hook name. Any remaining arguments
are passed to every callback executed at the hook location. So, a stub for a

lib/CGI/Application.pm  view on Meta::CPAN

    my ($c,@args) = @_;
    # ....
 }

Note that hooks are semi-public locations. Calling a hook means executing
callbacks that were registered to that hook by the current object and also
those registered by any of the current object's parent classes.  See below for
the exact ordering.

=cut

lib/CGI/Application.pm  view on Meta::CPAN

	die "Unknown hook ($hook)" unless exists $INSTALLED_CALLBACKS{$hook};

	my %executed_callback;

	# First, run callbacks installed in the object
	foreach my $callback (@{ $self->{__INSTALLED_CALLBACKS}{$hook} }) {
		next if $executed_callback{$callback};
		eval { $self->$callback(@args); };
		$executed_callback{$callback} = 1;
		die "Error executing object callback in $hook stage: $@" if $@;
	}

	# Next, run callbacks installed in class hierarchy

	# Cache this value as a performance boost
	$self->{__CALLBACK_CLASSES} ||=  [ Class::ISA::self_and_super_path($app_class) ];

	# Get list of classes that the current app inherits from
	foreach my $class (@{ $self->{__CALLBACK_CLASSES} }) {

		# skip those classes that contain no callbacks
		next unless exists $INSTALLED_CALLBACKS{$hook}{$class};

		# call all of the callbacks in the class
		foreach my $callback (@{ $INSTALLED_CALLBACKS{$hook}{$class} }) {
			next if $executed_callback{$callback};
			eval { $self->$callback(@args); };
			$executed_callback{$callback} = 1;
			die "Error executing class callback in $hook stage: $@" if $@;

lib/CGI/Application.pm  view on Meta::CPAN

=pod

B<Callback Ordering>

Object-based callbacks are run before class-based callbacks.

The order of class-based callbacks is determined by the inheritance tree of the
running application. The built-in methods of C<cgiapp_init>, C<cgiapp_prerun>,
C<cgiapp_postrun>, and C<teardown> are also executed this way, according to the
ordering below.

In a persistent environment, there might be a lot of applications

lib/CGI/Application.pm  view on Meta::CPAN

	CGI::Application::Plugin::Foo    foo_startup
	CGI::Application::Plugin::Bar    bar_startup

When C<My::App> runs, only C<foo_callback> and C<bar_callback> will
run.  The other callbacks are skipped.

The C<@ISA> list of C<My::App> is:

	My::App
	My::Project
	CGI::Application

This order determines the order of callbacks run.

When C<call_hook('init')> is run on a C<My::App> application, callbacks
installed by these modules are run in order, resulting in:
C<bar_startup>, C<foo_startup>, and then finally C<cgiapp_init>.

If a single class installs more than one callback at the same hook, then
these callbacks are run in the order they were registered (FIFO).



=cut