The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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!

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.

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 ...

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.

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(...)

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') ].