Get a pad of big sized post-it notes and start doing some preliminary design before you even think about "we'll need common routines for these things", "this.pl" or "that.php" or any other technological concern.
Sit down with another developer and start hashing things out : if you'll need a login screen write "login" on a postit, and tack it to the wall. If you need a way for users to query test data, put "search for old tests" on an postit, and tack it to the wall. As you and your colleague free associate, you'll change the association of the notes ("The query page should come after the login, and maybe we should have a description of how the query page works, and some links describing some basic queries on that page...") -- this is why I like using postit notes, you can shuffle them around as needed and keep things neater than a paper sketch or a whiteboard.

After some time you'll have a good collection of postits that should give you a rough idea of how your project design should look. Take each postit and start fleshing out the design for that particular item, what ui elements need to be present, business logic, and so on, and you'll have a good start on a solid design.

app_func.pm
Functions used by all other scripts: print page_header (whith navigation bar, window-title and app.-logo), print page_foot, connect to database, define colors and what not)

With regards to the printing functions, that sounds like what you actually want to do is have a look at the various templating modules, such as the shooting star Template Toolkit II.

Makeshifts last the longest.

Check out CGI::Application. For the web application I've been designing, its use of a single instance CGI script passing "run-modes" to the module has really helped me organize the application into logical sets of functions for each page. The documentation is pretty straightforward, IMNSHO, as well.

-rattus

update: whoops, left out a word

$app/bin           your main script and/or associated utilities
$app/etc           configuration files, persistent state
$app/lib           all of your modules or 3rd-party modules
                   you need to bundle
$app/var           any misc. state or files you create/use
                   at run-time (if any)
$app/doc           documentation (though a README or INSTALL
                   would be nice in $app/)
$app/htdocs        the web 'root' of your application, attached
                   to your web site using server configuration
[download]

Sometimes this is overkill (and it sounds like it might be for this particular project), but this is useful for keeping stuff organized and allows a project to be completely self-contained and portable.

it sounds like you're off to a pretty good start. for small to medium sized projects, that's about how i usually set it up, with a core module and a bunch of smaller scripts. at the very least, try to keep any sql out of the smaller scripts. as the project gets bigger, you can refactor by identifying important classes and putting them in their own seperate modules.

be careful about putting too much (any) display logic in that core module though. if you make good use of a templating engine like HTML::Template instead of having functions like 'navigation_bar','print_page_header', etc. it should be pretty easy. HTML::Template, and DBI also go quite well together.

and if you're doing testing, stick with the convention and have a subdirectory 't' with your test scripts in it and use Test::Harness to bring them together.

good luck with the literate programming. i haven't really found a satisfactory way to do it yet with perl. pod just doesn't cut it for literate programming.

anders pearson

weini