| Name : perl-CGI-Prototype
| |
| Version : 0.9054
| Vendor : obs://build_opensuse_org/devel:languages:perl
|
| Release : 6.2
| Date : 2015-06-09 04:50:14
|
| Group : Development/Libraries/Perl
| Source RPM : perl-CGI-Prototype-0.9054-6.2.src.rpm
|
| Size : 0.04 MB
| |
| Packager : (none)
| |
| Summary : Create a CGI application by subclassing
|
Description :
The core of every CGI application seems to be roughly the same:
* *
Analyze the incoming parameters, cookies, and URLs to determine the state
of the application (let\'s call this \"dispatch\").
* *
Based on the current state, analyze the incoming parameters to respond to
any form submitted (\"respond\").
* *
From there, decide what response page should be generated, and produce it
(\"render\").
the CGI::Prototype manpage creates a \'Class::Prototyped\' engine for doing
all this, with the right amount of callback hooks to customize the process.
Because I\'m biased toward Template Toolkit for rendering HTML, I\'ve also
integrated that as my rendering engine of choice. And, being a fan of clean
MVC designs, the classes become the controllers, and the templates become
the views, with clean separation of responsibilities, and \'CGI::Prototype\'
a sort of \"archetypal\" controller.
You can create the null application by simply _activating_ it:
use CGI::Prototype;
CGI::Prototype->activate;
But this won\'t be very interesting. You\'ll want to subclass this class in a
\'Class::Prototyped\'-style manner to override most of its 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, \'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 the
controlling class:
sub get_some_big_data {
my $self = shift;
return $self->some_other_method(size => \'big\');
}
And since the classes are hierarchical, you can start out with an
implementation for one page, then move it to a region or globally quickly.
Although the name \'CGI::Prototype\' implies a CGI protocol, I see no reason
that this would not work with \'Apache::Registry\' in a \'mod_perl\'
environment, or a direct content handler such as:
package My::App;
use base CGI::Prototype;
sub handler {
__PACKAGE__->activate;
}
Note that the \'$r\' request object will have to be created if needed if you
use this approach.
|
RPM found in directory: /packages/linux-pbone/ftp5.gwdg.de/pub/opensuse/repositories/devel:/languages:/perl:/CPAN-C/openSUSE_Tumbleweed/noarch |
