The thing that has helped me the most was realizing that so much of my
code had *nothing* to do with run modes and navigation, so didn't
really belong in a CGI::Application module at all. For example, I
might have a lot of functionality in a database. I move all of my SQL
into a separate MyApplication::DB module and abstract it into utility
functions for that application. I then add an accessor function to the
CGI::App module:
sub dbh {
my $self = shift;
if (!$self->{_dbh}) {
# create DB object
$self->{_dbh} = MyApplication::DB->new();
}
return $self->{_dbh};
}
(I think I took that code from one of Cees' examples to the list???)
So then I might have something like:
my @array = $self->dbh->getMyListofStuff();
in my CGI::Application module and let the DB module handle connecting,
disconnecting, SQL, joins, you name it. (I don't like "generic" SQL
abstraction, but custom abstraction FOR EACH PROJECT makes a lot of
sense to me.)
I've expanded this. I found in one project that I had lots of code
that just consisted of formatting raw data for display in the template.
Another spent a lot of time dealing with a particular external file.
My resulting CGI::Application module turns out to then be much cleaner,
and much easier to follow logically.
Of course, I've also ended up with a "SuperApp" module that
incorporates Sessions and authentication the way I wanted to do it,
plus overriding some templating behavior. So my "CGI::App modules" are
actually based on this SuperApp module. I think I'm going to look at
CheesePizza now, though, to see if I can glue all my modules together.
Not sure yet if I'll use it or just learn from it.
YMMV, of course. I'm more-or-less a shop of one, so I may have gone
about it completely bass-ackwards. :-)
Jaclyn
At 08:54 AM 4/8/2004, petersm wrote:
John Day wrote:
I am starting a new project today which is going to be bigger, and I
would
like to break things up. But if I put the run modes into modules of
their own
how do they get access to the params and to the CGI query for example?
I am reasonably new to OO-perl so I figure their is something I am
missing
here! Any advice appreciated.
You will need to split them up into their own modules where each is a
cgi-app
with it's own instance script. C::A will take care of making sure you
have a
CGI object and access to the params. Each instance module will have
it's own
params. If you need site wide params, I would store those in a config
file
where each module could access them.
Or, if you're a little more daring, you could check out the
CheesePizza. It's
a C::A which runs other C::A (plugins) and combines their output.
It's useful
for having separate modules to run things like the nav, a dynamic
side bar,
and a main content section all at the same time.
cheesepizza.venzia.com
Michael Peters
Venzia
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@xxxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: cgiapp-help@xxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@xxxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: cgiapp-help@xxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@xxxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: cgiapp-help@xxxxxxxxxxxxxxxxx
|
