What's easier about session handling in PHP is that I don't need another module
to use it; I can simply use it without installing anything else; if you want to
switch to memoery based sessions, it's a single config directive. And you can
switch to databases sessions by writing your own session container -- but you
simply define the methods for storing and retrieving, while PHP takes care of
the rest, like generating session IDs. Basically, it's one less dependency to
worry about.
Header access is really a moot point -- all you have to do in perl is print out
your headers to STDOUT; I probably should not have brought that one up. But when
it comes to your POST, GET, and COOKIE hashes, again, in PHP you don't need to
load another library to get access to those; you simply have them available.
Regarding database access in PHP, I actually don't use the database functions
directly. I install PEAR::DB (which you allude to), which is similar to DBI, as
what it does is abstract the calls for the various DB functions, and provides
things like prepared statements, convenience wrappers for simple things like
retrieving a single value or row, etc. I am aware that it is slower than ADODB,
but honestly, on the hardware I use, this isn't that big of an issue. If I want
an upgrade in speed, I'll probably switch to PEAR::MDB2 and/or PHP's PDO layer
(once stable). Finally, since I control my own servers, I only compile in
database support for those RDBMS' that I use.
(Which brings me to another point: I've seen a number of sites slam PHP for the
number of functions it has. However, not all functions are available by default;
if you compile PHP to only use the extensions you need, you can cut the number
of functions down tremendously. Granted, I've never understood the naming
conventions, nor why there are so many string functions that all do similar, but
not exactly the same, things.)
You mention CGI::Application::Plugin::ValidateRM... funny you should mention
that, as I finally ported the plugin functionality over to Cgiapp.clas.php in the 1.7.0
release, which happened this past Friday evening (20 May 2005). Bundled with
the class is Cgiapp_Plugin_HTML_QuickForm. HTML_QuickForm is a PEAR library for
form creation/validation, and is similar in functionality to
Data::FormValidator. It still needs a little testing and work -- integration
with template systems other than Smarty is currently untested -- but it does
work, and it makes form validation in Cgiapp a snap.
As I mentioned in my bio, the
reasons I ported CGI::Application are because it uses a paradigm that fits web
development, and my work situation mandates I program with PHP. The combination
of the run mode == method paradigm of CGI::Application with PHP is very
powerful, and makes for rapid development of reusable and
extendible applications -- two qualities I find I need on a daily
basis.
I really cannot make a case for using PHP + Cgiapp versus Perl +
CGI::Application; it really depends on the language you're most familiar with,
the server environment on which you'll be running your application, your work
situation (if relevant), etc. I can make a case for using
CGI::Application or Cgiapp -- and that case is made above: rapid development of
reusable and extendible web applications.
| [reply] |
Excellent ... look forward to trying Cgiapp out! Thanks.
| [reply] |