http://www.perlmonks.org?node_id=572400

jdtoronto has asked for the wisdom of the Perl Monks concerning the following question:

Esteemed monks,

I have a rather large Perl/Tk application, the codebase for which stretches back as far as 1997. It refuses to stop growing and for some totally inapparent reason, people keep wanting to use it and ask for all sorts of additions. I am now faced with making some changes that I think require a major overhaul - and I don't know how to do this, hence I supplicate myself before you seeking enlightenment.

What I have

The application is a reasonably sophisticated front end to MySQL, origianly it used just DBI but about two years ago I started adding Class::DBI into the mix and now it uses a mixture of both appproaches in different places.

Originally the whole thing was written following the example of Mastering Perl/Tk and was a single great big script. That was fine until it got to about 3000 lines. So I started to abstract logical sections into modules, which usually relate to something like a Tk::NoteBook panel, or some other chunk of GUI with logic. The config handle, the dbh handle and the MainWindow are all created near the top of the current 3700 line main code. The individual Tk::NoteBook panels are then 'created' and when the module is loaded a hash of configuration variables is passed in, like this:

my $excluder = MyApp::Exclude->new( -mw => $mw, -monitor => $monitor, -cfg => $cfg, -dbh => $dbh, ); $excluder->draw();
You can probably figure out what is happening, the -mw config variable is the MainWindow handle and is used to add the GUI elements, the -cfg and -dbh get the config and database handles.

Where I need to go

This monster now has a 3700 line main 'module' with about 40 self-written modules, all of which currently totals over 30,000 lines of custom code. And now I face a dilemna.

I want to add a Tk::StatusBar to the bottom of the main window, that's the easy part. But how do I expose the various methods for maniuplating the status bar to the many and varied places in my code which may want to toggle a little annunciator block, or manipulate a progress bar, or change a label text?

How do I structure something like this? Especially when some objects - which need ultimately to manipulate the MainWindw status bar, might be created by another object thus placing the child at a 'distance' from the Main?

I have tried understanding TheDamian through Object Oriented Perl and Perl Best Practices but my poor feeble brain seems to be not getting something.

jdtoronto

Replies are listed 'Best First'.
Re: How to structure LARGE Perl/Tk application?
by renodino (Curate) on Sep 11, 2006 at 21:37 UTC
    See Re: Perl Tk - propagating events...and this result from my own similar re-engineering effort.

    I wouldn't get too concerned about PBP stuff. I'd suggest sticking to basic OO and MVC; you may end up with code looking more like Java than Perl, but it will also probably be easier to maintain...and to eventually convert to AJAXy goodness, as I'm doing with most of my GUIs

      I've just been browsing your site. What's up with PSiCHE? It looks very interesting. Are the libraries available for download? Is the system usable for real work yet? Do you have some sample code? Insert inane question here?


      TGI says moo

        PSiCHE languishes.

        Mostly because Thread::Sociable languishes.

        Because I haven't won the lottery or inherited a large sum of money recently, and no one seems inclined to write checks sufficient to support the effort and resources required to complete it.

        Because the Perl(5) community seems content with fork and pipe.

        Which means I have to apply myself to other, more mundane, albeit profitable, pursuits, because its difficult to get a decent wifi signal from a refridgerator box on skid row.

        All of which is a damn shame. A recent thread on the Groovy lists pointed out a couple people presenting on concurrency models for Groovy. Based on concurrency stuff being added to Java, and soon, to Python. One such presentation is planned for codecamp. From which Perl appears to be completely absent.

        Which is (in part) why I'm spending more time reading Groovy books and maillists, than reading about/doing Perl these days.


        Perl Contrarian & SQL fanboy