Re: Programming style: using Classes or inline

[Daniel Kasak <dan entropy homelinux org>]

David wrote:
> I suppose this is more of a Perl question, but since I'm working with
> Gtk, maybe it will pass.. :)
>
> I'm quite new to Perl programming, and for starters, I have built a
> gtk-perl interface to my PostGresql business records database.

Cool. That's almost what I'm doing, but with MySQL & SQL Server :)

>   Some of
> my windows are built with glade using libglade and some are hand-built.
> Actually, I have three *.glade files - one for the main window, one for
> a database selection dialog and the other is a form for data entry,
> edit, or delete.  I have others which I built by hand.  After reading a
> recent message regarding using Glade, I may regret this.
>
> I first tried to keep my perl source separated into 3 files, all inline
> code without making any packages, including the other two into the main
> program by "use" statements, but when I added "use strict", I found that
> I had to tie the variables to a package, so I just made them all "my
> variables" - but, at least as far as I could see, they were not
> recognized across files, so I just merged them all into a single file.
>
> For a little perspective, my code now occupies some 1500+ lines.

Once I got to that point ( ie things got very messy ), I split things up 
like this:


main.pl
A script in the top-level application folder. Contains all global 
variables, like DBI handles, etc.

forms/
A folder to handle all code related to individual forms, eg:

forms/setup_user.pm  ( ie package forms::setup_user )
forms/logon.pm

reports/
A folder to handle report definitions ( more on this later )

glade/
Each window has a separate glade file in here

On startup, I do something like:

my $globals = {
       # Paths
           appdir        => $appdir,
           currentdir    => $currentdir,
           gladefiles    => $gladefiles,
           reports       => $appdir . "/reports",
           report_base   => $report_base,
           browser       => $browser,
           pdf_viewer    => $pdf_viewer,
          
       # Behaviour Flags
           userid        => $userid,
           no_maximize   => $no_maximize,
          
       # Database handles
           dbh           => $dbh,
           ms_dbh        => $ms_dbh,
           admin_dbh     => $admin_dbh,
          
       # Gtk2::Ex::DBI objects
           forms         => \$forms        # This MUST be a reference
         };

Instead of Gtk2::Ex::DBI objects ( directly above ), you can have 
Gtk2::GladeXML objects.

Then when someone goes to open a window, I go:

sub on_Prospects_btn_Search_clicked {
  
   if ( $forms->{company_search}->{form} ) {
      
$forms->{company_search}->{form}->get_widget("CompanySearch")->present;
   } else {
      $forms->{company_search} = forms::company_search->new( $globals );
   }
  
}

This way, I don't get duplicate copies of forms if people try to open a 
form again. You of course have to destroy the {form} object when you 
close the window ... elsewhere.

> Also, if I were to adapt some of the routines to Classes, what's
> normally best - separate files or a single file?

Separate files are good for me. It means you can effortlessly move 
windows between applications just by copying the entire file. When you 
make changes, you just copy the altered file around.

If you're doing database stuff, you should check out my website:
http://entropy.homelinux.org/axis_not_evil

I've automated a LOT of the mundane stuff required for dealing with 
databases. Everything is extremely well tested on MySQL ( and kinda 
tested with SQL Server ). I'd love to have some feedback from Postgres 
users ... as long as they don't start flaming me for using MySQL :) I've 
got Gtk2::Ex::DBI for dealing with 'normal' forms ( ie Access forms ), 
and Gtk2::Ex::Datasheet::DBI for dealing with ... datasheet ... type 
things. I've also got PDF::ReportWriter for doing printable reports. I'm 
on the verge of a 1.1 release of this, which will have full XML report 
definition support :) Stay tuned for this 'real soon now'.

Dan