Re: HTML::Table - Advice please

Thanks to the both of you who have answered thus far.

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!

Comment on Re: HTML::Table - Advice please

Replies are listed 'Best First'.
(jeffa) Re: HTML::Table - Advice please by jeffa (Bishop) on Dec 16, 2002 at 04:37 UTC
"... 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)	[reply]
Re: Re: HTML::Table - Advice please by CountZero (Bishop) on Dec 16, 2002 at 07:17 UTC
Just some more random thoughts. Perhaps this a useful scheme: 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] 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.. 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	[reply] [d/l]