view release on metacpan or  search on metacpan

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

package CGI::Snapp;

use strict;
use warnings;

use Carp;

use Class::ISA;

use Log::Handler;

use Moo;

use Try::Tiny;

has _current_run_mode =>
(
	is       => 'rw',
	default  => sub{return ''},
	required => 0,
);

has _error_mode =>
(
	is       => 'rw',
	default  => sub{return ''},
	required => 0,
);

has _headers =>
(
	is       => 'rw',
	default  => sub{return {} },
	required => 0,
);

has _header_type =>
(
	is       => 'rw',
	default  => sub{return 'header'},
	required => 0,
);

has logger =>
(
	is       => 'rw',
	default  => sub{return ''},
	required => 0,
);

has _object_callbacks =>
(
	is       => 'rw',
	default  => sub{return {} },
	required => 0,
);

has PARAMS =>
(
	is       => 'rw',
	default  => sub{return {} },
	required => 0,
);

has _params =>
(
	is       => 'rw',
	default  => sub{return {} },
	required => 0,
);

has _prerun_mode_lock =>
(
	is       => 'rw',

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

=item o __QUERY_OBJ => L</query([$q])>

=item o __RUN_MODES => L</run_modes([$option])>

=item o __START_MODE => L</start_mode([$run_mode])>

=item o __TMPL_PATH => Not implemented

=back

The leading '_' on some CGI::Snapp method names means all such methods are for the exclusive use of the author of this module.

=head3 New methods

=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)>

=item o L</send_output([$Boolean])>

=back

=head3 Deprecated methods

=over 4

=item o L</header_add(@headers)>

See L</How does add_header() differ from header_add()?>.

=back

=head3 Unsupported methods

=over 4

=item o html_tmpl_class()

=item o load_tmpl()

=item o run_as_psgi()

=item o tmpl_path()

=back

See below for details.

=head3 Enchanced features

=over 4

=item o Use of utf8::downgrade() to turn off utf8 bit on headers

=item o Use of Try::Tiny rather than eval

Ideally, this won't be detectable, and hence won't matter.

=item o call_hook(...) returns a hashref - keys are 'class' and 'object' - of counts of hooks actually called

=item o delete_header(A list)

See L</delete_header(@keys)> for how to delete any number of HTTP headers.

=item o Calling the error_mode() method

This call is protected by Try::Tiny.

=item o Calling mode_param([...])

mode_param() can be called with an arrayref, as in $self -> mode_param([qw/path_info -2/]). See t/run.modes.pl for details.

=item o Calling param([...])

param() can be called with an arrayref, as in $self -> param([qw/six 6 seven 7/]). See t/params.pl for details.

=back

=head3 No special code for Apache, mod_perl or plugins

I suggest that sort of stuff is best put in sub-classes.

For the record, I don't use Apache or mod_perl. For web servers I use L<Engine X|http://wiki.nginx.org/Main>, L<mini_httpd|http://www.acme.com/software/mini_httpd/>, L<Starman> and (for development) L<Plack>.
As it happens, I don't use any plugins (for L<CGI::Application>) either.

So, it's not that I refuse to support them, it's just that I won't put any special code in place unless asked to do so. And then, only if it fits into my philosophy
of where this code is headed. And that includes potential re-writes of L<CGI::Application::Dispatch>, L<CGI::Application::Dispatch::PSGI> and L<CGI::Application::Server>.

=head3 Upper-case parameters to L</new()>

Yes, I know SHOUTING parameter names is ugly, but I<some> back-compat feautures must be supported, right?. Hence L</new()> accepts PARAMS and QUERY.

=head3 Template Mangement

L<CGI::Snapp> contains no special processing for L<HTML::Template>, or indeed any templating system. Rationale:

There is no support because I see L<CGI::Application>'s usage as a manifestation of an (understandable) design fault. If anything, TMPL_PATH should have been CONFIG_PATH.

That is, one of the methods in your sub-class - cgiapp_init(), cgiapp_prerun() or setup(), or a hook - should load a config file, and in that file is the place to put a template path,
along with all those other things typically needed: Paths to CSS and Javascript libraries, database connexion parameters, etc.

Then, each different sub-class can load a different config file, if necessary, and hence use a different set of templates. Likewise, testing and production versions of config files
can be deployed, and so on.

For example, first read in a hashref of config options (see L<Config::Plugin::Tiny>), and then set up a rendering engine:

	use Config::Plugin::Tiny; # For config_tiny().
	use Text::Xslate;
	...
	$self -> param
	(
		config => config_tiny('/some/dir/some.file.ini');
	);
	$self -> param
	(
		renderer => Text::Xslate -> new
		(
		input_layer => '',
		path        => ${$self -> param('config')}{template_path},
		)
	);

Then, later, use the renderer like this (in a View component of the MVC style):

	my($output) =
	{
		div     => 'order_message_div',