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

Hi.. I've made some simple Tk apps, used a bunch of the different widgets, but I'm now wanting to put together an application that is more sizeable in the tasks it performs and the hardest part for me is how to organize the code. I'm using a "Notebook" widget to hold 4 tabs worth of functionality. Each tab is then a sizeable screen holding a number of other widgets.

One layout I pondered was that the functionality(subs) for each screen(tab of notebook) should be each be in their own namespace.(package) Another was I should keep everything in one namespace and just pre-pend the subroutine names with the name of the screen/tab they act upon.

Re-organizing code after its written can be somewhat painful, so I'd appreciate any perspectives or links to help me decide. thanks!

Replies are listed 'Best First'.
Re: Seeking input on perl/Tk code design
by kvale (Monsignor) on Mar 19, 2004 at 17:00 UTC
    For large perl/Tk projects, I usually put all the gui code for each window or dialog into it own _ui routine. So for your project, I would use notebook_ui, tab1_iu, etc. The helper routines for each _ui would be in proximity to the _ui sub.

    As I project grows, I move each _ui + helper subs into it's own module, for ease of locating subs. Creating a namespace for each module is a good idea if you think there will be a lot of collisions among sub names; otherwise, don't bother with it and just disambiguate sub names.

    Unless you have a whole lot of interaction between different tabs' subs, this should be pretty painless to do incrementally.

    -Mark

Re: Seeking input on perl/Tk code design
by matija (Priest) on Mar 19, 2004 at 16:19 UTC
    How much code do the "tabs of notebook" share? If they share a lot, perhaps you'd be better off if you put the common routines into one or more modules (so that you can even reuse it in other projects).

    If, on the other hand, each tab has completely separate routines, they you'd be well justified in putting each tab into it's own (or more than one) module.

    I should warn you, however, that you might find moving the subroutines into modules after the app is more or less working takes (in my experience) much more work than if you did it right (and modular) in the first place. Often, it takes more effort than it would to just rewrite the thing from scratch.

      The code/logic for each tab is going to be quite different. All the tabs will be operating off of the same database connection, but each tab will be centered around a different purpose.(different tables/areas of the database)

      I'll have some administrative tabs which I'll use to update(or add/remove) items in the database, and then more tabs which will be centered around either reporting(generated on tab load) or a near real-time(refreshed) view of the data. Its basically an admin GUI - make a configuration changes on one tab, then click a few tabs over to wait for a visible effect resulting from your changes. Other than the database connection I don't think the tabs will share much code/logic.