This is an article discussion thread for discussing the SitePoint article, "CGI::Application: A Simple, Extensible Web Framework"
| SitePoint Sponsor |
This is an article discussion thread for discussing the SitePoint article, "CGI::Application: A Simple, Extensible Web Framework"
Thank you for the links. I was taught to us MVC in my Java programing classes in college and also with PHP. Even though I know very little if any thing about Pearl. It was interesting to see MVC used in Pearl anyway!
First of all - great stuff, man!
I used to love CGI::Application, but one day I found CGI::Application::Plus, which made me absolutely happy.
I've integrated HTML::Template::JIT (compiler for templates) into it, and became happiest coder in the world.
Few weeks ago a good friend of mine gave me link to http://perl.4pro.net/ , a homepage of CGI::Builder.
It's next stage of CGI::Application::Plus evolution.
Now I'm migrating.
Check it out, it worth the time you'll spent learning it.
falcn at gamer.com.ua
Thanks for the heads up re: CGI::Builder. I'll look into it.
Dan
CGI::Application::Plus and CGI::Builder have been written by another author. And CGI::Application is still being developed (check the last release date). Even more - check the numerous plugins for it ...
in the DFV example, for the password constrain
password =>[ { constraint => qr/^\w{6,10}$/ }, ... }
can't you write the following?
password =>[ { qr/^\w{6,10}$/, ..... }

If you are interested in Perl frameworks, Catalyst is another option. I've used Catalyst and CGI::Application; they both have their strong points.
Yes, Catalyst is a strong alternative. It has a steep learning curve for those new to frameworks IMHO, and is trying to occupy the same space as Ruby on Rails. But it is nice to use, and some of the team has been working on DBIx::Class - an alternative ORM to Class:BI which of played with briefly and like.
CGI::Application works well for those who need a simple, lite framework. It doesn't require the huge dependency list of pre-requisite modules. So it's horses for courses, I guess.
Last edited by redbone; Feb 28, 2006 at 12:19. Reason: fixed typo
Hi,
Can someone show me how to integrate the "Extending CGI::Application"-Part?
I have changed:
...Code Perl:package MyApp::User; use strict; use base 'MyApp::Base';
and i have made
...Code Perl:
But:
$self->prerun_mode('login');
is ignored.
regards
este
Are you calling the sub from some where? Subroutines have to be called in order to evaulate whats inside of them.
Dear all,
Based on this article I made a webapplication.
For that a have to examine a DNA Sequence for validity.
Code Perl:sub _primer_profile { my $self = shift; use Bio::Seq; return { required => [qw( sequence id)], filters => ['trim'], constraints => { sequence => [ { name => 'dirty_sequence', constraint => sub { my $self = shift; my $seq = shift; return !($seq =~ m/([^ATCG\n\r\s])/i); }, params => [$self, 'sequence'] } { name => 'open_sequence', constraint => sub { my $self = shift; my $sequence = shift; $sequence =~s/\s//sg; my $seq = Bio::Seq->new(-id => 'seq', -seq => $sequence, -alphabet => 'dna' ); my $l = $seq->length(); my $erg = $l % 3; return ($erg == 0); }, params => [$self, 'sequence'] } ], }, msgs => { prefix => 'err_', missing => 'No Value entered!', constraints => { 'dirty_sequence' => 'Input is not valid!', 'open_sequence' => 'Discontinuous reading-frame', } } }; } #------------------------------------------------------------------------------ # Process the submitted sequnce #------------------------------------------------------------------------------ sub maintain_sequence { my $self = shift; my $q = $self->query; # validate the input use CGI::Application::Plugin::ValidateRM (qw/check_rm/); my ($results, $err_page) = $self->check_rm('display_primer_form', '_primer_profile'); return $err_page if $err_page; $self->display_result_form(); }
I want to have more the one error message for one form field.
So I use multible constraints.
First, the alphabet is checked. Allowed is only "A,T,G,C".
Second, the nubmer of characters has to be divided per 3.
The Problem is, that only the second subroutine is working.
Maybe the second overwrites the first.
Please have a look in the code.
It would be very nice if you can help me.
best regards
stephan
I don't know if CGI::Application::Plugin::ValidateRM used to work differently, but $results on line 6 of maintain_user() contains 'trim'med $q->param()'s from the submitted form. So, if a user put ' Mark' as the first_name, in order to get the trimmed 'Mark' result into the database, $results->valid('first_name') has to be used instead of $q->param('first_name'). In other words, _create_user() and _update_user can't just use $q->param(...) They need to use $results->valid(...)
A great resource - many thanks!
As of version 1.20 of CGI::Application::Plugin::ConfigAuto, which was released after this article was published, the plugin's documentation recommends that:
use CGI::Application::Plugin::ConfigAuto (qw/cfg cfg_file/);
instead be
use CGI::Application::Plugin::ConfigAuto (qw/cfg/);
and that
my $webapp = MyApp::User->new();
$webapp->cfg_file('myapp.cfg');
instead be
my $webapp = MyApp::User->new(
PARAMS => { cfg_file => 'myapp.cfg' } );
But I am finding that the name of the configuration file set in that anonymous hash must use either an absolute path such as cfg_file => '/path/to/myapp.cfg', or a path relative to the location of the instance script that uses a leading '.' or '..' such as cfg_file => './myapp.cfg' when the config file is in the same directory as the instance script. (Using cfg_file => 'myapp.cfg' isn't enough, even if the config file is in the same directory as the instance script.)
I am using a Linux box, Config::Auto ver. 0.20, and CGI::Application::Plugin::ConfigAuto ver. 1.30).
I now believe the need to specify the path and name of the config file (not just the name of the config file) arises only when the instance script is being run in taint mode (-T on the first line of the instance script) and the config file is in Perl syntax (which the ConfigAuto plugin discovers through the magic of Config::Auto). Config::Auto's documentation explains that a Perl-syntax config file is eval'ed using Perl and that the config file is read by a "do( $config_filename )" command. So the evaluation of a config file that has no pathname specified is considered to bring in tainted data, causing the instance script to fail (alas, with an unhelpful "no such file or directory" error message that points to a line in Config::Auto). The environment "PATH" has not been explicitly set by the instance script, and Perl doesn't trust the script to run with whatever PATH is currently in effect on the system (which might be the target of monkey business by an intruder). So the taint can be avoided if a path to the configuration file is specified to the ConfigAuto plug-in, either as an absolute path or a path that is relative to the location of the instance script).
Another quirk, though: the syntax used in this article for specifying the configuation file, which the author of the updated plug-in no longer recommends, doesn't work for me even if the instance script is not in taint mode (without the -T flag) and even if the path to the Perl-syntax config file is provided. I get this error:
cfg_file: must have at least one config file. at [filename with path of the application module] line XX [XX being the line where the module first attempts to access a configuration parameter using $self->cfg('parameter_name_here') ].
So don't use this
my $webapp = MyApp::User->new();
$webapp->cfg_file('myapp.cfg');
but use this instead
my $webapp = MyApp::User->new(
PARAMS => { cfg_file => '/path/to/myapp.cfg' }
);
What a difference a T makes!
Bookmarks