IMO there are two things that need to be done before you should be looking at the presentation layer.
  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.

In reply to Re: HTML::Table - Advice please by Ryszard
in thread HTML::Table - Advice please by meetn2veg

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.