One of the major advantages of seperating presentation from code is being able to change the presentation without changing the code. This allows people such as web designers to come in and redesign a website without the programmer having to change his code to fit that new design.

I can personally say that HTML::Template works great for me and allows for easy design changes. As for being able to manipulate tables using HTML::ElementTable, you can't get much more powerful than changing the raw HTML.

I think the area where my code would shine is when you have a table, and you want to insert data and shift everything else. Instead of moving braces and commas and rearranging, you just put the new cell in there.

The same thing applies to changing the number of rows or columns. Change one number and you're done. If you want, you can even choose the size based on a user preference.

The spec looks nice. I havn't looked through the code yet. OTOH, I'd name it HTML::Tables, as this has nothing to do with the CGI interface.

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

When developing web apps I prefer to have the HTML code in a template. You can use HTML::Template for it. That way your tables are also created dynamically. What you have to do is put your data in the array+hash structure. Then you can change the appearance of the table by editing template or global CSS. That way the code and presentation are separate.

Did you not see my attempt at this problem:
DBIx::XHTML_Table? You can even use that module
to create a "Spreadsheet CGI". However, mine is more tied to
DBI ... but you can always pass the constructor an AoA without needing a database.

This does make me wonder if there should be a base class that both of our modules could use ... on another note, i
would like to see your module replace HTML::Table,
which i really don't care for. The author actually tries to
handle each attribute individually instead of generically
allowing attributes to 'handle themselves' ...
shudder

Anyhoo, check out my module ... there are some neat features
you are welcome to steal. :) (like rotating attributes and
callbacks for each cell)

Oh yeah, i almost forgot -- if you want to investigate the
HTML::Template solution, be sure and check out my
Dynamic HTML::Template Database Template. Again, it was designed to be generic and to
be used with a database, but you can always modify it to fit
your specific needs.

I hadn't seen DBIx::XHTML_Table before. It is the 96th result returned in a CPAN search for "html table". I rarely search to the 10th page. Truth be told, there are entirely too many results returned. Many of them seem to do the same thing, and most of them also seem poorly designed, IMOH.

<rant>

Some people will naturally like templates better. That's fine, but let's ignore that at the moment, because I personally don't care much for them. They have their place, but most of the time it's not with me.

Where is the best place to put a module like this? I see them in all different namespaces: DBIx, HTML, Table, Text, CGI. Where would it actually belong? If it's made more generic with different output options? What if you decide you want to expand it with other HTML functions? This is a general problem with CPAN, I think. Reusable code doesn't fit well in a hierarchy.

Now what if different people have different ideas of what a good interface would be? The first module claims a good name, and the second really has no place.

Suppose, for instance that I decide I don't like the way CGI.pm works. I decide that I want to redesign it. Sure, reinventing the wheel can be bad, but there's always the possibility of improvement. What would I name my module?

</rant>

It's really hard to find the right module sometimes. Too hard. I suppose it's even harder to write one.

It's curious that in the same burst you rant about too many modules being on CPAN and having them poorly designed, but you offer no feedback at all on DBIx::XHTML_Table, which apparently has support for using an AoA to build the table, which I think is supposed by be one of the neat features of your module-- the easy ability to add a column.

My suggestion is that you if you are concerned about the proliferation of semi-useful modules on CPAN, look hard at all the alternatives to your own module that you could contribute to before starting yet-another.

I get the sense that many modules are maintained by primarily one person who would be glad to have help, and we would all benefit by having fewer high quality modules to wade through.

If you remain confident your module is filling a unique niche, I think the module-authors@perl.org mailing list is the appropriate place to ask about potential names.

Before I noticed Text::Table was around, I made a similar module which I called, of all things, Text::Table. However, unlike the one on CPAN, mine supports outputting to plain text, CSV, or HTML. You have more support for coloring and style, etc., but we both seem to be reinventing wheels.