Sorry. Figured out my own answer. Following below:
in CGI::App,
$self->dbh->dbh is now a database handle.
Sean
On Oct 1, 2004, at 8:46 AM, Sean Davis wrote:
Jaclyn,
Again, thanks for the help. I am working on producing something like what you propose. I have a database module that works with a simple perl script, but when I add it into my CGI::App with an accessor subroutine, I always get:
Can't locate object method "selectrow_array" via package "ntDBH" at /Library/Perl/5.8.1/CGI/Session/MySQL.pm
which is now understandable as I'm using CGI::Session with mysql storage, so I need to have straight DBI methods available to CGI::Session. I'm thinking that I have two options:
1) open a second database handle directly to DBI (not ideal) 2) inherit DBI methods in my ntDBH package
I'm looking at how to do 2. Any hints? I know this is more a perl question than CGI::App, but I thought folks (like me) might benefit from seeing the answer. I don't want to abuse the list, though, so direct me elsewhere or ignore....
Thanks, Sean
On Sep 30, 2004, at 4:10 PM, Jaclyn Whitehorn wrote:
On Sep 30, 2004, at 2:52 PM, Sean Davis wrote:
I am building a cgi::application that queries pretty extensively (at least for me) from a MySQL database. I am having trouble with maintainability, as the SQL code is mixed into the perl code and, unfortunately, we are changing the database schema fairly often right now. I was wondering what hints folks have about managing the SQL parts away from the logic of the code. For my limited programming skills, writing subroutines within my CGI::App is easiest but probably not the most flexible.
In my last project, I was running into the same type of problem. I ended up backing up from the code and looking at the process, then splitting into multiple modules. This particular project ended up with:
(1) A CGI::Application module (well, actually based on my SuperApp subclass of CGI::Application)
(2) A module to handle database stuff
(3) A module to handle .procmailrc stuff (which if I could avoid forever, I'd be happy)
(4) A module to handle some generic formatting tasks (taking stuff from db and formatting for web and vice-versa)
After the split, the main CGI::Application-based module ONLY handled taking info from user, simple logic, and putting stuff back. Since my session management and some display tasks are done in my SuperApp, this module is 275 lines total. Much nicer IMHO.
So, how to handle the DB? I added an accessor function to my CGI::App module, based on some code Cees Hek (I think??) posted a while back:
sub dbh { my $self = shift; if (!$self->{_dbh}) { # create DB object $self->{_dbh} = MyDB->new(); } return $self->{_dbh}; }
where MyDB is my database module, which is of course "used" at the beginning.
In MyDB.pm, new() handles the connection, and DESTROY handles the disconnect. Then I coded all the queries and updates I would do to this particular project, some in a generic sense and others not. So in my CGI::App module I end up with calls like:
$self->dbh->get_list('prefs',$userid);
YMMV...
Jaclyn
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
