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/Plugin/REST.pm  view on Meta::CPAN

The following functions are available.  None of them are exported by default.
You can use the C<:all> tag to import all public functions.

=cut

# Plug in to CGI::Application and setup our callbacks
#
sub import {
    my $caller = scalar caller;

    $caller->add_callback(

 view release on metacpan or  search on metacpan

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

    if ( ! UNIVERSAL::isa($callpkg, 'CGI::Application') ) {
        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 the prerun_callback method in the docs for more info)";
    }
    else {
	    #Add the required callback to the CGI::Application app so it executes the routes_parse sub on the prerun stage
        $callpkg->add_callback( prerun => 'routes_parse' );
    }

 view release on metacpan or  search on metacpan

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

=begin pod-coverage

=over 4

=item strip_name - we hook into this to install cgiapp callbacks

=item parse_proto - proto parser

=item inject_parsed_proto - turn it into code

 view release on metacpan or  search on metacpan

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

=begin pod-coverage

=over 4

=item parse_mode - we hook into this to install cgiapp callbacks

=item parse_name - identifier name parser

=item parse_signature - runmode signature parser

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

    - added AUTO_SUGGEST, AUTO_SUGGEST_FILE, AUTO_SUGGEST_CACHE and AUTO_SUGGEST_LIMIT
        functionality
    - minor doc fixes
    - fixed mispelling of 'global_var' => 'global_vars' in HTML::Template
        options
    - removed use of callbacks since they didn't really add anything
        and required newer versions of C::A
    - better and more complete sample templates that are installed with
        the application and useable when no others are provided.
    - split tutorial out into a separate file and include some setup
        info for AJAX usage.

 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

 view release on metacpan or  search on metacpan

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

The HTML generated by C<prepare> can be influenced by a number of attributes
of the form object and group/field sub-object(s) (manipulate via hash keys, only some accessor methods have been defined as yet).
To get the $field sub-object (hashref) try C<$group-E<gt>{field_hash}{FIELD_NAME}> (see also C<field_hash>).
Some of the following attributes may have content already so it is best to append to them, rather
than assign/replace their values. C<prepare> also accepts some callbacks to allow further customization.
Unless otherwise noted, custom content is expected to be HTML (encode with HTML entities, etc, see C<escape>).

=over

=item $form->{top_message}

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

    {
        my $valerr = $self->escape($field_s->{VALID_ERROR});
        $head = $self->escape($field_s->{HEADING});
        $head = $self->_process_field_head($field_s,$head,$group);

        # all callbacks must be responsible for escaping any added HTML
        $val = &{$self->{val_callback}}($val,$field_s,$self) if ref($self->{val_callback});

        my $class;
        $class .= "$label_class_add " if $label_class_add;
        $class .= "REQ " if $field_s->{REQUIRED} eq 'Y';

 view release on metacpan or  search on metacpan

lib/CGI/Builder/LogDispatch.pm  view on Meta::CPAN

        );
    } else {
        require Log::Dispatch::Screen;
        %defaults = ( name=>'default'
                    , min_level=>'warning'
                    , callbacks => sub { sprintf "[%s] %s\n", Date::Format::time2str('%Y-%m-%d %H:%M:%S',time), $_[1] }
                    );
        $logger->add(
            Log::Dispatch::Screen->new( %defaults, %{$self->logger_config} )
        );
    }

 view release on metacpan or  search on metacpan

lib/CGI/Parse/PSGI/Streaming.pm  view on Meta::CPAN

        # the filehandle; it will be called with no argument (or an
        # undef) when the filehandle is closed
        my ($data) = @_;

        # reset the default filehandle to the real STDOUT, just in
        # case: it's nice to make sure all the callbacks are invoked
        # with the state they expect
        my $saver = SelectSaver->new("::STDOUT");

        # if we're still parsing the headers
        if (!$response) {

 view release on metacpan or  search on metacpan

t/2_fill_18_coderef.t  view on Meta::CPAN

# -*- Mode: Perl; -*-

=head1 NAME

2_fill_18_coderef.t - Test CGI::Ex::Fill's ability to use coderef callbacks

=cut

use strict;
use Test::More tests => 4;

 view release on metacpan or  search on metacpan

lib/CGI/FormBuilder/Field.pm  view on Meta::CPAN

=head1 METHODS

=head2 new($form, %args)

This creates a new C<$field> object. The first argument must be a reference
to the top-level C<$form> object, for callbacks. The remaining arguments
should be hash, of which one C<key/value> pair must specify the C<name> of
the field. Normally you should not touch this method. Ever.

=head2 field(%args)