Re: [cgiapp] Splitting large projects.

[Jaclyn Whitehorn <suppressed>]

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/suppressed/
> >              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
> > To unsubscribe, e-mail: suppressed
> > For additional commands, e-mail: suppressed
>
>
> ---------------------------------------------------------------------
> Web Archive:  http://www.mail-archive.com/suppressed/
>               http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
> To unsubscribe, e-mail: suppressed
> For additional commands, e-mail: suppressed


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
             http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed