Program design in perl?

[Mohammd M. Hussain]

Hi,

I have a good knowledge of Perl ( 2 and half years ) and despite
working with the language that long, I have yet to build a substantial
program ( during this time I was merely testing out various aspects of
the language ). I have tried many times to build a program like a web
blog or a bulletin board but it seems that my attempts fail as soon as
I fire up the text editor! I just cannot determine what is the optimal
design to use when coding a web application.

So, I would love to read about how you guys organise your Perl code.

Thanks,

 

[penguinista]

Hi,

I have a good knowledge of Perl ( 2 and half years ) and despite
working with the language that long, I have yet to build a substantial
program ( during this time I was merely testing out various aspects of
the language ). I have tried many times to build a program like a web
blog or a bulletin board but it seems that my attempts fail as soon as
I fire up the text editor! I just cannot determine what is the optimal
design to use when coding a web application.

So, I would love to read about how you guys organise your Perl code.

Thanks,

One good approach, not just for perl, is to start by laying out the data
your project will need to deal with. A project can live or die on good
or bad data organization. List the operations needed on that data, as
these will influence the prefered representation of the data, and may
indicate additional data fields needed. For persistant data (blog,
bulitin board), consider interfacing a database (module DBI). Or if you
prefer a flat file, start coding with routines to read/write records.

 

[Mohammad Mahmoud Khajah]

One good approach, not just for perl, is to start by laying out the data
your project will need to deal with. A project can live or die on good
or bad data organization. List the operations needed on that data, as
these will influence the prefered representation of the data, and may
indicate additional data fields needed. For persistant data (blog,
bulitin board), consider interfacing a database (module DBI). Or if you
prefer a flat file, start coding with routines to read/write records.

Thanks for your reply,

I would like to know more details: How to handle errors ( I mean is it by
using exceptions or regular return codes ) and How the overall structure
of good modular web application should look like.

I coded an OO database interface for a blog program and
I have made it loosely-coupled so I can test it quickly and it turned out
to be fine. I would love to read suggestions about the next step(s) after
creating an abstraction layer for the DB.

 

[Skeleton Man]

I would like to know more details: How to handle errors ( I mean is it by

using exceptions or regular return codes ) and How the overall structure
of good modular web application should look like.

Error handling during the development stage would be something like this:
(using a file read as an example)

$fname = "/path/to/file";
open (FILE, "<$fname") || die ("Unable to open $fname: $!");

If the program is gonna be released to the masses, it may be better to have
error codes and an FAQ:

$fname = "/path/to/file";
open (FILE, "<$fname") || die ("Errror 123: Consult FAQ for details !");

As for structure, personally I prefer to split a program into a series of
libraries and actions:

Example:

myscript.cgi?action=someaction
File structure:

/cgi-bin/myscript.cgi
-- Script itself
/cgi-bin/myscript_actions/
-- Directory of files with code related to specific tasks
/cgi-bin/myscript_actions/someaction/
-- Subdirectory for the specific action "someaction"
/cgi-bin/myscript_actions/someaction/code_for_this_function.pl -- Code
related to the specific action.


If you go to http://www.guestwho.com and download "GuestWho" (perl
guestbook, flatfile), you can get an idea of how I choose to structure to my
programs. This is just personal preference, there's not really a right or
wrong way to approach it.

I coded an OO database interface for a blog program and
I have made it loosely-coupled so I can test it quickly and it turned out
to be fine. I would love to read suggestions about the next step(s) after
creating an abstraction layer for the DB.

Start by thinking of one the major tasks (viewing, posting, etc) and what's
involved (such as user input, verification, etc).
Once you know what that task needs to do and what's involved with it, start
thinking about how you're going to tackle it.

After you have one task done, repeat the above with another task..


DISCLAIMER: The above is my prefered methods of operation, but I make no
claim that it is the best or only way to do it.

Regards,
Chris