Just some preliminary questions before we can really start thinking about this:

1. Is your data going to reside in a database?
2. Do you know how much tables will be required beforehand?
3. Is the structure of each table known beforehand (number of fields; type of field; ...?

Having recently been dealing quite a lot with databases, I'm of course biased in this direction ...

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

But like i said first - use a templating system. It has proven itself to me to be the most flexible so far ... check out HTML::Template Tutorial for a simple intro to that module.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

1. Get the client to agree on what they want
2. Model your data

Point 1 is pretty straight forward, how can you design something that the client hasnt agreed to!? Do a google, and search for a business analysis/requirement template. You should be looking for headings in the template like "scope", "requirments" etc etc. Of course every developers requirements templates are different, so what you are after is a template that defines (at a high level) the concepts that will define the project. For example "A system that will allow the mass dissemination of motor trial events. The system will also allow for the input and update of each event."

Once the client has agreed (signed-off) on a top level concept, you could start on a more detailed design. This design should (for a small project) outline the logic and exceptions of the workflow. Once this is done, show the client, get them to sign if off.

Even tho' asking the client to sign off the spec's may seem obvious, it is a very effective way to clearly define the project and manage expectations. If the client changes their mind 1/2 thru' you can point to the spec's and say "Phase II". Its a perfectly reasonable thing to do.

Once you've got the design down, you can model the data. It sounds to me like you've got a pretty good candidate for a relational datamodel. You would have a couple of concepts, perhaps "racers", "events" and "results". Nice and simple. Your racers and events structures would have a primary key, and your results structure could be a combination of the events and racers structures with additional information such as rank.

Notice how i havent talked about a RDBMS yet? As Jeffa mentioned DBD::SQLite might be a good way to go, as may a tied hash... My personal preference *would* be an RDBMS such as postgres, MySQL, Oracle et al.. Keep in mind, if you're going to use flat files, you will almost certainly have troubles with integrity and locking at some stage.

Once you've done all the "hard" stuff you should be set up nicely to produce anything you like quite easily. Using CGI::Application (which has a dependency on HTML::Template) you could quite easily build a fairly sexy website with dynamic content. Having a sexy structure means you can pull all kinds of statistics out of your database such as a link that would produce a list of all events and places for an individual contestant.

Its all about the design baby..

Disclaimer: Some of the links in this node are off site and may not be available at time of reading.

Being an annual event makes it a real pain. If whatever code I end up with were to be used more frequently, it wouldn't bother me so much!!! Such is life.

Anyway, data will be stored in flatfiles (for the moment - providing I come up with a managable way to edit them!). HTML::Template is installed on the server and I have been toying with the idea of using that module either on its own or in combination with HTML::Table.

I suppose my first hurdle would be to decide on a sensible method of storing the moto-trial data and the table data. I'm driven towards separate files which could easily be read, combined and written to a *.html file on the server (the whole system is not dynamic - 'published' pages are written to disk - that's the way I wrote the thing 6 months ago but would now love to change the damn thing!)

Client doesn't really know what she wants (possibly the worst type of client?) but sees what the likes of MS Excell can do when you go File:Save as... HTML then turns to me and says "Can your program do that?!?"

Anyway - the number of tables in use may vary. Certainly the number of columns (between 6 and 9) and the number of rows (participants in each event/category/level). Therefore I'm well aware that the data will change from table to table. I had thought of creating a series of templates with HTML::Template but gut feeling said it was not the correct way to go - my stomach knows the client?! Even using the FOR loops or IF/ELSE routines in HTML::Table didn't feel right.

I'm sure I'll need to write 2 GUI's: 1 to create/edit Table defs (ie:cols, rows, bgcolor, etc) for which the data would be stored in a flat file, and the 2nd GUI for entering the data (still haven't decided on the best method for entering data or for storing it!).

I've already used htmlArea (wysiwyg TEXTAREA editor) for other interfaces for this client and she seems OK with it. I found out that it loads table templates quite nicely but the resulting page is saved as straight HTML - table data and event data mixed.

I'm really looking for a quick and dirty way out of this one. Next year, I'll re-write the system, next year they'll have more funds, and next year my invoice to them will be bigger! (if I decide to continue with these guys!)

In other words I don't want too many people wasting their time - although at the moment it's more than grately appreciated!

"... data will be stored in flatfiles ..."

I highly recommend that you consider DBD::SQLite instead. Then, when the time comes to switch to a "real" relational database, the process will be much smoother. Also, read A Guide to Installing Modules for information on installing modules in your user space when you don't have root access.

' then turns to me and says "Can your program do that?!?"'

Sure it can ... with the right tools and little work on your behalf. If this were my problem, i would store the data in either a relational database like MySQL or Postgres, or SQLite - then, you can transform that data into HTML, XML, XHTML, an Excel spreadsheet (via Spreadsheet::WriteExcel), YAML ... whatever. Check out DBD::AnyData - you can even use it on a flat file. The CPAN has plenty of 'toys' to make this a fun project. I hope you can find the enjoyment out of putting these Lego™ blocks together, especially in time for the holidays. ;)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Just some more random thoughts.

Perhaps this a useful scheme:

1. The user creates an XML-like file which describes the tables to use (a template can be provided, so they just have to copy & paste and fill-in the blanks

   <TABLE>
   <NAME>tablename</NAME>
   <TITLE>This is the title of the first table>/TITLE>
   <COLUMN>First Column Title</COLUMN>
   <COLUMN>Second Column Title</COLUMN>
   <COLUMN>Third Column Title</COLUMN>
   </TABLE>
   <TABLE>
   <NAME>tablename</NAME>
   <TITLE>This is the title of the second table>/TITLE>
   <COLUMN>First Column Title</COLUMN>
   <COLUMN>Second Column Title</COLUMN>
   <COLUMN>Third Column Title</COLUMN>
   </TABLE>
   [download]

2. Then you have as much flat text files as there are tables (each with the name of the table as filename), which are really tab-separated value files with one record per line, containing the data of this table..
3. You could then either compile this bunch of files once into the web-site you need or interprete them on-the-fly for each access to the site (this means the user can keep on changing the tables and data and only has to upload the files to the server by FTP or so -- of course you would need some checking the uploaded files to see that they are "valid").
As the structure is rather simple, you will perhaps not need a full-blown XML::Parser in your program.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Matt