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 all matches for this distribution
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 all matches for this distribution
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 all matches for this distribution
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 all matches for this distribution
view release on metacpan or search on metacpan
- 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 all matches for this distribution
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 all matches for this distribution
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 all matches for this distribution
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 all matches for this distribution
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 all matches for this distribution
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)
view all matches for this distribution
view release on metacpan or search on metacpan
lib/CGI/Framework.pm view on Meta::CPAN
B<OPTIONAL>
If this key is supplied, it should contain the value to be used in the <form> HTML element's "action" parameter. If not supplied, it will default to environment variable SCRIPT_NAME
=item callbacks_namespace
B<OPTIONAL>
This key should have a scalar value with the name of the namespace that you will put all the validate_templatename(), pre_templatename(), post_templatename(), pre__pre__all(), post__pre__all(), pre__post__all() and post__post__all() subroutines in. ...
The main use of this option is to allow you, if you so choose, to place your callbacks subs into any arbitrary namespace you decide on (to avoid pollution of your main namespace for example).
=item cookie_domain
B<OPTIONAL>
lib/CGI/Framework.pm view on Meta::CPAN
}
#
# We implement validation if possible
#
if ($validate_template && defined &{"$self->{callbacks_namespace}::validate_$validate_template"}) {
&{"$self->{callbacks_namespace}::validate_$validate_template"}($self);
if ($self->{_html}->{_errors}) {
#
# The validation didn't go so well and errors were recorded
# so we re-show the template the failed validation
lib/CGI/Framework.pm view on Meta::CPAN
#
# An alias to new(), to be used in nooop mode
#
sub initialize_cgi_framework {
my %para = ref($_[0]) eq "HASH" ? %{ $_[0] } : @_;
$para{callbacks_namespace} ||= (caller)[0] || "main";
return new("CGI::Framework", \%para);
}
#
# The constructor. Initializes pretty much everything, returns a new bless()ed instance
lib/CGI/Framework.pm view on Meta::CPAN
}
#
# Backwards compatability support
#
foreach (qw(callbacks_namespace cookie_name import_form initial_template sessions_dir templates_dir valid_languages)) {
$temp = $_;
$temp =~ s/_//g;
if (!exists $para{$_} && exists $para{$temp}) {
$para{$_} = $para{$temp};
delete $para{$temp};
lib/CGI/Framework.pm view on Meta::CPAN
#
# We set some defaults if unsupplied
#
$para{valid_languages} ||= [];
$para{callbacks_namespace} ||= (caller)[0] || "main";
if (!$para{cookie_name}) {
$para{cookie_name} = "sessionid_$ENV{SCRIPT_NAME}";
$para{cookie_name} =~ s/[^0-9a-z]//gi;
}
if (!$para{sessions_mysql_dbh} && !$para{sessions_dir}) {
lib/CGI/Framework.pm view on Meta::CPAN
#
# It's a code ref - good
#
}
elsif (defined &{"$self->{callbacks_namespace}::$para{output_filter}"}) {
#
# It's a sub name that exists. good
#
$para{output_filter} = &{"$self->{callbacks_namespace}::$para{output_filter}"};
}
else {
croak "Output filter not a code ref and not a sub name that I can find";
}
}
lib/CGI/Framework.pm view on Meta::CPAN
#
$self->{action} = $para{action};
$self->{valid_languages} = $para{valid_languages};
$self->{templates_dir} = $para{templates_dir};
$self->{initial_template} = $para{initial_template};
$self->{callbacks_namespace} = $para{callbacks_namespace};
$self->{log_filename} = $para{log_filename};
$self->{disable_back_button} = $para{disable_back_button};
$self->{output_filter} = $para{output_filter};
$self->{_cgi} = new CGI || die "Failed to create a new CGI instance: $! $@\n";
$cookie_value = $self->{_cgi}->cookie($para{cookie_name}) || undef;
lib/CGI/Framework.pm view on Meta::CPAN
my $content;
my $content_type;
no strict 'refs';
if (defined &{"$self->{callbacks_namespace}::pre__pre__all"}) {
#
# Execute a pre__pre__all
#
&{"$self->{callbacks_namespace}::pre__pre__all"}($self, $template_name);
}
if (defined &{"$self->{callbacks_namespace}::pre_$template_name"}) {
#
# Execute a pre_ for this template
#
&{"$self->{callbacks_namespace}::pre_$template_name"}($self, $template_name);
}
if (defined &{"$self->{callbacks_namespace}::post__pre__all"}) {
#
# Execute a post__pre__all
#
&{"$self->{callbacks_namespace}::post__pre__all"}($self, $template_name);
}
#
# Parse template
#
lib/CGI/Framework.pm view on Meta::CPAN
}
print "\n";
print $content;
$self->session("_lastsent", $template_name);
if (defined &{"$self->{callbacks_namespace}::pre__post__all"}) {
#
# Execute a pre__post__all
#
&{"$self->{callbacks_namespace}::pre__post__all"}($self, $template_name);
}
if (defined &{"$self->{callbacks_namespace}::post_$template_name"}) {
#
# Execute a post_ for this template
#
&{"$self->{callbacks_namespace}::post_$template_name"}($self);
}
if (defined &{"$self->{callbacks_namespace}::post__post__all"}) {
#
# Execute a post__post__all
#
&{"$self->{callbacks_namespace}::post__post__all"}($self, $template_name);
}
if (!$nofinalize) {
$self->finalize();
}
view all matches for this distribution
view release on metacpan or search on metacpan
lib/CGI/Info.pm view on Meta::CPAN
=head3 Validation Subroutine Support
The C<allow> parameter accepts subroutine references for dynamic validation,
enabling complex parameter checks beyond static regex patterns.
These callbacks:
=over 4
=item * Receive three arguments: the parameter key, value and the C<CGI::Info> instance
view all matches for this distribution
view release on metacpan or search on metacpan
lib/CGI/Inspect.pm view on Meta::CPAN
string for what they want printed. All of the built-in plugins actuall inherti
from L<CGI::Inspect::Plugin>, which just provides some convenience methods. The
main CGI::Inspect module will create an instance of your plugin with
Plugin->new, and then will execute it with $plugin->process.
Plugins can, however, make use of Continuity, including utilizing callbacks.
Here is the complete source to the 'Exit' plugin, as a fairly simple example.
package CGI::Inspect::Plugin::Exit;
use strict;
lib/CGI/Inspect.pm view on Meta::CPAN
foreach my $plugin (@{$self->{plugin_objects}}) {
$content .= $plugin->process();
}
}
$self->display($content);
$request->next->execute_callbacks
unless $self->{do_exit};
} until($self->{do_exit});
$request->print("<script>window.close();</script>");
Coro::Event::unloop();
$request->print("Exiting...");
view all matches for this distribution
view release on metacpan or search on metacpan
MxScreen.pm view on Meta::CPAN
#
# ->compute_screen
#
# Compute target screen, and run and enter/leave hooks if we change screens.
# This routine does not display anything, but runs all the action callbacks.
#
# Returns new screen object, and a ref to the argument list.
#
sub compute_screen {
DFEATURE my $f_;
MxScreen.pm view on Meta::CPAN
=item *
C<CGI::MxScreen> uses C<Carp::Datum> internally. If you have chosen to
install a non-stripped version, you may trace parts of the module to better
understand what is going on with the various callbacks you register.
=back
=head2 Flow
MxScreen.pm view on Meta::CPAN
86 $manager->play();
87
This finally launches the state machine: the next state is computed, action
callbacks are fired, and the target screen is displayed.
=head2 More Readings
To learn about the interface of the C<CGI::MxScreen> manager object,
see L<"INTERFACE"> below.
MxScreen.pm view on Meta::CPAN
=head1 SPECIFIC DATA TYPES
This sections documents in a central place the I<state> and I<callback>
representations that can be used throughout the C<CGI::MxScreen> framework.
Those specifications must be serializable, therefore all callbacks
are expressed in various symbolic forms, avoiding code references.
Do not forget that I<all> the arguments you specify in callbacks and screens
get serialized into the context. Therefore, you must make sure your
objects are indeed serializable by the serializer (which is C<Storable>
by default, well, actually C<CGI::MxScreen::Serializer::Storable>, which is
wrapping the C<Storable> interface to something C<CGI::MxScreen> understands).
See L<CGI::MxScreen::Config> to learn how to change the
MxScreen.pm view on Meta::CPAN
=head2 Utility Path
The concept of I<utility path> stems from the need to keep all callback
specification serializable. Since C<Storable> cannot handle CODE references,
C<CGI::MxScreen> uses function names. In some cases, we have a default
object to call the method on (e.g. during action callbacks), or one can
specify an object. In some other case, a plain name must be used, and you
must tell C<CGI::MxScreen> in which packages it should look to find that name.
This is analogous to the PATH search done by the shell. Unless you specify
an absolute path, the shell looks throughout your defined PATH directories,
MxScreen.pm view on Meta::CPAN
etc... That's what the utility path is.
The routine C<CGI::MxScreen::add_utils_path> must be used I<before> the
creation of the C<CGI::MxScreen> manager, and takes a list of strings,
which define the package namespaces to look through for field validation
callbacks and patching routines. The reason it must be done I<before>
is that incoming CGI parameters are currently processed during the
manager's creation routine.
=head1 LOGGING
view all matches for this distribution
view release on metacpan or search on metacpan
lib/CGI/OptimalQuery.pm view on Meta::CPAN
# format a value before it is executed in the database
=item B<< is_hidden => 1 >>
hides the select field and data from being viewed by the user. Data for this select is still available in callbacks and can be included in the hiddenFilter.
=item B<< always_select => 1 >>
tells OptimalQuery to always select the column regardless if it isn't explicitly being used in the show. This does not automatically make it shown to the user, but it will be available to the developer in callbacks.
=item B<< select_sql => (STRING | ARRAYREF) >>
=item B<< filter_sql => (STRING | ARRAYREF) >>
lib/CGI/OptimalQuery.pm view on Meta::CPAN
This is an advanced feature that can help perl guru's change the factory blueprints for optimal query modules instantiated by CGI::OptimalQuery.
=item B<< named_filters => { NORMAL_NAMED_FILTER, CUSTOM_NAMED_FILTER, .. } >>
allow developers to create complex predefined sql for insertion in the where clause by the 'filter' and 'hiddenFilter' parameters. There are two types of named_filters: "normal" and "custom". Normal named filters are defined with static SQL. Custom n...
=over
=item B<< NORMAL_NAMED_FILTER >>
lib/CGI/OptimalQuery.pm view on Meta::CPAN
=item B<< OQdataLCol => sub { } >>
=item B<< OQdataRCol => sub { } >>
Specify custom code to print the first or last column element. This is most often used to generate an view/edit button. If these callbacks are used, the editLink, and buildEditLink are ignored.
OQdataLCol => sub {
my ($rec) = @_;
return "<button onclick=\"OQopwin('/ViewRecord?id=$$rec{U_ID};on_update=OQrefresh';\">".
"view</button>";
view all matches for this distribution
view release on metacpan or search on metacpan
lib/CGI/PrintWrapper.pm view on Meta::CPAN
You could just call C<print> yourself on the appropriate file handle,
but there are many contexts in which it is cleaner to provide the
extra abstraction (such as mixing B<CGI> with B<HTML::Stream>, the
problem which prompted my solution, illustrated above).
B<CGI::PrintWrapper> creates the necessary callbacks for printing
dynamically, updating the symbol table as it encounters a new B<CGI>
method.
=head1 CONSTRUCTOR
view all matches for this distribution
view release on metacpan or search on metacpan
lib/CGI/Prototype.pm view on Meta::CPAN
behavior. Slots can be added to add or alter behavior. You can
subclass your subclasses when groups of your CGI pages share similar
behavior. The possibilities are mind-boggling.
Within the templates, C<self> refers to the current controller. Thus,
you can define callbacks trivially. In your template, if you need some
data, you can pull it as a request:
[% my_data = self.get_some_big_data %]
which is supplied by simply adding the same slot (method or data) in
view all matches for this distribution
view release on metacpan or search on metacpan
lib/CGI/Screen.pm view on Meta::CPAN
C<last_screen> returns screen name and title in list context and
screen name in scalar context. Do not use the CGI parameters
C<screen_last_*> since they are changed before you can get hold of
them C<;-P>
=head2 The callbacks
All callbacks are called with three arguments: The query object, the
screen name and the screen title (= button/anchor text). Callbacks
should return a string.
=item C<application>
The C<application> method returns a string which is used
in the default C<title> and C<headline> callbacks. The Default method
returns the string C<"CGI::Screen Test"> and should definitely be
overwritten by your application.
=item C<title>
view all matches for this distribution
view release on metacpan or search on metacpan
lib/CGI/Snapp.pm view on Meta::CPAN
is => 'rw',
default => sub{return ''},
required => 0,
);
has _object_callbacks =>
(
is => 'rw',
default => sub{return {} },
required => 0,
);
lib/CGI/Snapp.pm view on Meta::CPAN
is => 'rw',
default => sub{return 'start'},
required => 0,
);
my(%class_callbacks) =
(
error => {},
forward_prerun => {},
init => {'CGI::Snapp' => ['cgiapp_init']},
prerun => {'CGI::Snapp' => ['cgiapp_prerun']},
lib/CGI/Snapp.pm view on Meta::CPAN
$hook = lc $hook;
$self -> log(debug => "add_callback($hook, ...)");
croak "Error: Unknown hook name '$hook'\n" if (! $class_callbacks{$hook});
if (ref $self)
{
# it's an object-level callback.
my($object_callback) = $self -> _object_callbacks;
$$object_callback{$hook} = [] if (! $$object_callback{$hook});
push @{$$object_callback{$hook} }, $option;
$self -> _object_callbacks($object_callback);
}
else
{
# It's a class-level callback.
push @{$class_callbacks{$hook}{$self} }, $option;
}
} # End of add_callback.
# --------------------------------------------------
lib/CGI/Snapp.pm view on Meta::CPAN
my(%seen);
# Call object-level hooks.
for my $callback (@{${$self -> _object_callbacks}{$hook} })
{
next if ($seen{$callback});
try
{
lib/CGI/Snapp.pm view on Meta::CPAN
# Call class-level hooks.
for my $class (Class::ISA::self_and_super_path(ref $self || $self) )
{
next if (! exists $class_callbacks{$hook}{$class});
for my $callback (@{$class_callbacks{$hook}{$class} })
{
next if ($seen{$callback});
try
{
lib/CGI/Snapp.pm view on Meta::CPAN
} # End of _generate_output.
# --------------------------------------------------
sub get_callbacks
{
my($self, $type, $hook) = @_;
$type ||= '';
$hook ||= '';
$self -> log(debug => "get_callbacks($type, $hook)");
croak "Error: \$type parameter to get_callbacks() must be 'class' or 'object'\n" if ($type !~ /^(?:class|object)$/);
croak "Error: \$hook parameter to get_callbacks() must be a string\n" if (length($hook) == 0);
return $type eq 'class' ? $class_callbacks{$hook} : ${$self -> _object_callbacks}{$hook};
} # End of get_callbacks.
# --------------------------------------------------
sub get_current_runmode
{
lib/CGI/Snapp.pm view on Meta::CPAN
$hook = lc $hook;
$self -> log(debug => "new_hook($hook)");
$class_callbacks{$hook} ||= {};
return 1;
} # End of new_hook.
lib/CGI/Snapp.pm view on Meta::CPAN
Aren't you glad that was the I<simple> view?
=head2 A More Complex View
L<CGI::Snapp> and before it L<CGI::Application> are designed in such a way that some of those methods are actually I<callbacks> aka I<hooks>, and their names are looked up via hook names.
See the Wikipedia article L<Hooking|http://en.wikipedia.org/wiki/Hooking> for a long explanation of hooks.
It works like this: A hook name is a key in a hash, and the corresponding value is a package name, which in turn points to an arrayref of method names. So, for a given hook name and
package, we can execute a series of named methods, where those names are listed in that arrayref.
lib/CGI/Snapp.pm view on Meta::CPAN
An explanation:
=over 4
=item o Yes, there are class-level callbacks and object-level callbacks
See L</add_callback($hook, $option)> for details.
=item o The error hook
lib/CGI/Snapp.pm view on Meta::CPAN
That name is either pre-defined (see L</new_hook($hook)>) or one of your own, which you've previously set up with L</new_hook($hook)>.
Sample code:
# Class-level callbacks.
$class_name -> add_callback('init', \&method_1);
KillerApp -> add_callback('init', 'method_2');
# Object-level callbacks.
$app = CGI::Snapp -> new;
$app -> add_callback('init', \&method_3);
Notes:
=over 4
=item o Callback lifetimes
Class-level callbacks outlive the life of the $app object (of type L<CGI::Snapp> or your sub-class), by surviving for the duration of the Perl process, which, in a persistent
environment like L<Starman>, L<Plack>, etc, can be long enough to serve many HTTP client requests.
Object-level callbacks, however, go out of scope at the same time the $app object itself does.
=item o The class hierarchy
Callbacks can be registered by an object, or any of its parent classes, all the way up the hierarchy to L<CGI::Snapp>.
=item o Callback name resolution
Callback names are checked, and only the first with a given name is called. The type of callback, class or object, is ignored in this test, as it is in L<CGI::Application>.
This also means, that if there are 2 callbacks with the same name, in different classes, then still only the first is called.
Consider:
In Class A: $self -> add_callback('teardown', 'teardown_sub');
In Class B: $self -> add_callback('teardown', 'teardown_sub');
lib/CGI/Snapp.pm view on Meta::CPAN
Only the pre-defined hooks are called by L<CGI::Snapp>. So, if you use your own name in calling new_hook($name), you are also responsible for triggering the calls to that hook.
The pre-defined hooks are called 'error', 'init', 'prerun', 'postrun' and 'teardown', and there is no need to call L</new_hook($hook)> for those.
=item o Class-level callbacks
These belong to the class of the object calling L</add_callback($hook, $option)>.
=item o Multiple callbacks for a given hook
If multiple I<class>-level callbacks are added for the same hook by different classes, they will be executed in reverse-class-hierarchy order.
That it, the callback for the most derived class is executed first. This is the way normal class-hierarchy overrides work - nothing unexpected here.
If multiple I<class>-level callbacks are added for the same hook by the same class, they will be executed in the order added, since they are pushed onto a stack (as are object-level
callbacks).
If multiple I<object>-level callbacks are added for the same hook, they are run in the order they are registered, i.e. in the order of calls to L</add_callback($hook, $option)>.
=item o The 'init' hook
Since the 'init' hook is triggered during the call to L</new()>, even before L</setup()> is called, there is no opportunity for normal end-user code (your sub-class of L<CGI::Snapp>) to attach
a callback to this hook.
lib/CGI/Snapp.pm view on Meta::CPAN
Alternately, examine the source code of L<CGI::Snapp::Plugin::Forward> for another way to do things, although it uses 'forward_prerun' rather than 'init'.
=back
To summarize, you are I<strongly> advised to examine t/hook.test.pl and all the modules it uses to gain a deeper understanding of this complex issue. In particular, the order of 'use'
statements in your sub-class of L<CGI::Snapp> will determine the order in which class-level callbacks are triggered.
=head2 add_header(@headers)
Adds headers to the list which will be sent to the HTTP client.
lib/CGI/Snapp.pm view on Meta::CPAN
=head2 call_hook($hook, @args)
Call the named hook. $hook is forced to be lower-case.
Returns a hashref of the number of callbacks actually called, where the keys are 'class' and 'object', and the values are integer counts.
@args takes various values, depending on the name of the callback:
=over 4
lib/CGI/Snapp.pm view on Meta::CPAN
Deprecated.
See also L</add_header(@headers)>, L</delete_header(@keys)>, L</header_props([@headers])>, L</header_type([$option])> and L</How does add_header() differ from header_add()?>.
=head2 get_callbacks($type, $hook)
Gets callback information associated with the given $type (class/object) and $hook.
$type is 'class' for class-level callbacks, and 'object' for object-level callbacks.
Values for $type:
=over 4
=item o 'class'
get_callbacks('class', $hook) returns a I<hashref>.
The keys of this hashref are the class names which have registered callbacks for $hook.
The values of this hashref are arrayrefs of method names or references.
=item o 'object'
get_callbacks('object', $hook) returns an I<arrayref>.
The values of this arrayref are arrayrefs of method names or references.
=back
lib/CGI/Snapp.pm view on Meta::CPAN
=head3 Always call croak and not a combination of croak and die
Also, every message passed to croak matches /^Error/ and ends with "\n".
=head3 No global variables (except for the inescapable dispatch table of class-level callbacks)
This means things like $$self{__CURRENT_RUNMODE} and $$self{__PRERUN_MODE_LOCKED} etc are only be available via method calls.
Here is a list of the global variables in L<CGI::Application>, and the corresponding methods in L<CGI::Snapp>, in alphabetical order:
lib/CGI/Snapp.pm view on Meta::CPAN
=item o __HEADER_TYPE => L</header_type([$option])>
=item o __HTML_TMPL_CLASS => Not implemented
=item o __INSTALLED_CALLBACKS => L</installed_callbacks()>
=item o __IS_PSGI => _psgi()
=item o __MODE_PARAM => L</mode_param([@new_options])>
lib/CGI/Snapp.pm view on Meta::CPAN
=over 4
=item o L</add_header(@headers)>
=item o L</get_callbacks($type, $hook)>
=item o L</log($level, $string)>
=item o L</logger($logger_object)>
view all matches for this distribution
view release on metacpan or search on metacpan
Widget/HList.pm view on Meta::CPAN
CGI::Widget::HList::Node tree graph. For more information,
see L<CGI::Widget::HList::Node>.
This module is where image configurations, node rendering,
and connector rendering methods are stored in the form of
callbacks.
Check ex/ for example scripts
=head2 Constuctors
Widget/HList.pm view on Meta::CPAN
root Root node of the tree to be rendered
Images to be used in the HTML rendering of the tree:
img_open,img_close,img_leaf,img_trunk,img_branch,img_corner,img_spacer
The rendering methods themselves. All are callbacks:
render_node,render_branch,render_spacer,render_trunk
The rendering methods default to sensible code that uses the (also
default) images. This can all be over-ridden. See Methods.
view all matches for this distribution
view release on metacpan or search on metacpan
XMLApplication.pm view on Meta::CPAN
E.g. event_init handles the init event described below.
Each event has a single Parameter, the context. This can be an unblessed
hash reference or an object, where the user can store whatever needed.
This context is useful to pass scriptwide data between callbacks and
event functions around. The callback is even available and useable if
the script does not initialize the application context as earlier shown
in the program flow chart.
If such a function is not implemented in the application module,
XMLApplication.pm view on Meta::CPAN
=back
If errors occour on a certain stage of serialization, the application
is stopped and the generated error messages are returned.
CGI::XMLApplication provides four pseudo-callbacks, that are used to
get the application specific information during serialization. In
order of being called by CGI::XMLApplication::serialization() they
are:
=over 4
view all matches for this distribution
view release on metacpan or search on metacpan
lib/CHI/Cascade/Rule.pm view on Meta::CPAN
created by this rule in notation described in L<CHI/"DURATION EXPRESSIONS">. The
B<default> is 'never'. It can be B<coderef> or B<string scalar> format as
L<CHI/"DURATION EXPRESSIONS">. A B<coderef> to be called as C<<
$coderef->($rule) >> and should return expire time as string value. You can use
this method inside L<CHI::Cascade/code> and L<CHI::Cascade/recomputed> your
callbacks if you want to force recomputing of current target through minimum
this time.
=back
=head1 AUTHOR
view all matches for this distribution
view release on metacpan or search on metacpan
lib/CLI/Gwrapper/wxGrid.pm view on Meta::CPAN
}
return $grid;
}
# Button callbacks
sub onClick_Execute {
my ($self, $button, $event) = @_;
my @cmd_line = (
$self->command->[0], # the CLI command
view all matches for this distribution
view release on metacpan or search on metacpan
Debian_CPANTS.txt view on Meta::CPAN
"libmarc-crosswalk-dublincore-perl", "MARC-Crosswalk-DublinCore", "0.02", "0", "0"
"libmarc-lint-perl", "MARC-Lint", "1.44", "0", "1"
"libmarc-perl", "MARC", "1.07", "0", "1"
"libmarc-record-perl", "MARC-Record", "2.0.3", "0", "0"
"libmarc-xml-perl", "MARC-XML", "0.92", "0", "0"
"libmasonx-interp-withcallbacks-perl", "MasonX-Interp-WithCallbacks", "1.18", "0", "0"
"libmath-algebra-symbols-perl", "Math-Algebra-Symbols", "1.21", "0", "1"
"libmath-base36-perl", "Math-Base36", "0.09", "0", "0"
"libmath-base85-perl", "Math-Base85", "0.2", "0", "0"
"libmath-basecalc-perl", "Math-BaseCalc", "1.016", "0", "0"
"libmath-basecnv-perl", "Math-BaseCnv", "1.8.B59BrZX", "0", "0"
view all matches for this distribution
view release on metacpan or search on metacpan
//-------------------------------------------------------------------
/** Mutex to serialize servant calls from omniORB. Allows the mutex
* to be temporarily released to allow callbacks with a deeper
* recursion level to execute.
*/
class POmniRatchetLock {
omni_mutex mutex_;
view all matches for this distribution
view release on metacpan or search on metacpan
corpus/dists/IUP.changes view on Meta::CPAN
- fixing broken links to examples
=head2 06/02/2013 - 0.100
- updating callbacks newly added in iup 3.6/3.7
- starting new version line
=head2 12/08/2012 - 0.006
- attribute accesors now handled via AUTOLOAD
corpus/dists/IUP.changes view on Meta::CPAN
- added: IUP::Canvas::(Palette|Pattern|Stipple|Bitmap) - canvas helper modules
- added: IUP::Canvas::(InternalState|InternalServerImage|InternalContext) - canvas helper modules (hidden)
- added: IUP::Canvas::FileBitmap
- added: IUP::Canvas::FileVector - replacement for IUP::Canvas::(SVG|EMF)
- added: IUP::ConfigData
- fix for callbacks: better handling of callbacks with no return value (fallback to IUP_DEFAULT)
- fix for callbacks: MULTITOUCH_CB, MULTISELECTION_CB, MULTIUNSELECTION_CB, NODEREMOVED_CB
- removing debug stuff 'use Data::Dump(er)'
=head2 29/07/2011 - 0.002
- removing invalid accessors "0" and "1"
view all matches for this distribution
view release on metacpan or search on metacpan
# Todo for CPAN::Common::Index
- base class needs support for logging callbacks: log_debug,
log_info, log_warn
view all matches for this distribution
view release on metacpan or search on metacpan
lib/File/Process.pm view on Meta::CPAN
=back
=head1 CAVEATS
Processing each line using hooks and callbacks can introduce
inefficiencies in file processing. This class is meant to be used on
moderately sized files. In it's basic forms, the methods will read all
lines into memory as it iterates over the file. Your processing may
not require that lines be accumulated at all. Your custom C<process()>
or C<filter()> hook can choose to return an undefined value which
view all matches for this distribution
view release on metacpan or search on metacpan
t/README.md view on Meta::CPAN
Test::More::subtest that is reasonably compatible back to 0.88. If using
subtests, you must not set a plan in the subtest and you must use
done_testing in the *.t file.
The TestML::Tiny library contains functions for parsing and executing TestML
tests with callbacks. TestML is a data-driven testing language; TestML::Tiny
implements a small subset of its features. See the section on TestML, below,
for an example. Generally, bugs should be patched upstream on CPAN and then
a new Test::Tiny CPAN release can be copied here and pod-stripped.
The TestBridge library contains testing functions for use in .t files or to
be passed to TestML::Tiny functions as callbacks. Test functions should not
include `done_testing`. They should use `subtest` for any repetitive testing
that loops over test cases. Callback should check for the expected test
points (see below) and skip a TML block if those points are not available.
The TestUtils library contains utility functions. Testing functions should
view all matches for this distribution
view release on metacpan or search on metacpan
vhost/html/js/tiny_mce/plugins/fullscreen/fullscreen.htm view on Meta::CPAN
// Override options for fullscreen
for (var n in paSe.fullscreen_settings)
settings[n] = paSe.fullscreen_settings[n];
// Patch callbacks, make them point to window.opener
patchCallback(settings, 'urlconverter_callback');
patchCallback(settings, 'insertlink_callback');
patchCallback(settings, 'insertimage_callback');
patchCallback(settings, 'setupcontent_callback');
patchCallback(settings, 'save_callback');
view all matches for this distribution