> As for SQL, I just wish people would expand their horizons a little
> and start doing a bit of reading. There are so many different ways
> to avoid embedding SQL in application code and I sincerely wish
> programmers would THINK before just coding... it's what
> differentiates scripters from engineers and I suggest everyone who
> embeds SQL in their perl for anything other than quick-and-dirty
> hacks start considering other options for the good of the
> programming community AND THE SANITY OF WHOMEVER HAS TO MAINTAIN OR
> ALTER YOUR CODE.
> I just implore readers of this list to start thinking more as
> engineers and less as script kiddies. We all love mod_perl and its
> power and we want it to succeed. We'll only get somewhere with it
> if we actually make the effort to write better code. Mixing SQL and
> perl is not better code.>
WHY? WHY WHY WHY WHY???? Tell me why it's this horrible, glue-sniffing,
script-kiddie badness to do something in a clear and simple fashion????
Below is a pseudo-code handler. It talks to the database:
use strict;
use vars qw/$dbh/;
sub handler {
my $r = shift;
lookup_info($r);
# ... blah...
return OK;
}
sub lookup_info {
my $r = shift;
# ||= allows an already connected $dbh to skip reconnect
$dbh ||= DBI->connect(My::dbi_connect_string(), My::dbi_pwd_fetch())
or die DBI->errstr;
# WARNING! "amateur" code ahead!!!
my $sql_lookup_password = $dbh->prepare_cached( <<SQL );
SELECT passwrd, pageid
FROM siteinfo si, pages pg
WHERE si.acctid = pg.acctid
AND si.acctid = ?
AND pageno = 0
SQL
($c_pass, $c_pid) =
$dbh->selectrow_array( $sql_lookup_password, undef, $acctid );
return undef unless defined $c_pass and $pass eq $c_pass;
# We've confirmed the password.
return $c_pid if !$pid or $pid eq $c_pid;
# some more logic, maybe even another query
return $pid;
}
Now. Tell me ONE thing that's wrong with this? The statement handle is
clearly named ($sql_lookup_password), the query is either A) really simple
or B) commented w/ SQL comments, C) if I change my schema, the query is
RIGHT THERE in the only place that acually USES it.
OO is an idea for "cleaning up" and "packaging" functionality. Fine. If I
need it that bad, I'll code my handler as an object. But let's not forget
that the underlying mechanism, no matter how fancily layered, is still a
list of FUNCTION CALLS. OO has its place. ABSOLUTELY. In perl I can
create an FTP connection _object_ and tell it what to do, and trust that it
knows how to handle it. But in the REAL WORLD, my script is its own
"object", with its own guts and implementation, and the "interface" is:
MyModule::handler. Apache knows what function to call. I can mess with the
guts and the interface doesn't change.
So what do I gain by adding 6 layers of indirection to something this
simple? OO has its PLACE as a TOOL. It should not be a jail with LOCKED
DOORS and ARMED ESCORT. (and come to think of it, any objects I use aren't
cons :-)
My $.02.
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
