From: Austin Ziegler <austin@...>
Date: 2003-06-12T05:32:05+09:00
Subject: Re: HTML-table

> Austin Ziegler wrote:
>> Can I suggest some changes to what you've got? I am in part
>> suggesting these because I have to create a Table class for my
>> PDF generator as well, and I think it would be good *as much as
>> is possible* to make them similar. What I am thinking is an
>> overarching Table class that implements the base functions and
>> then an HTML::Table that inherits from it; similarly, a
>> PDF::Table would inherit from it as well.
> Sounds interesting. I guess I would need to know more about
> PDF::Table. What distinguishes what you need from a regular HTML
> Table?

Everything. (Sorry.) I have to render the table distinctly and it's
actually quite complex (and there are a few more options). I'm
already planning on making a table class for PDF documents; I'm just
thinking that the *basic* structure of tables is pretty consistent
no matter the output format. I can show you some of the code for
rendering tables for PDF off-line (it's not really clean yet, and it
doesn't yet use the table API that I plan on making, but where I'm
going should be evident).

> I originally was going to make Row a subclass of Table (and Data a
> subclass of Row, etc), but I didn't because they don't really
> qualify as subclasses IMHO. It was causing to many design
> problems, with subclasses having access to variables/data they
> really shouldn't have access to. Maybe if I were a better OO
> programmer...

I haven't actually looked at your code yet -- the rendering may need
to get that deep, but I do think that there are some classes that
can be done. However, what I was suggesting is not Row < Table (I
don't think that there's an is-a relationship there) but Table::Row
-- a name space relationship. That is,

  class Table
    class Row
    end
  end

> However, I like the '<<' and 'table[0]' syntax. That's easy enough
> to add, I think.

The biggest change that I think I'd want to see is *removing* any
evidence that the methods are specifically HTML. Table#add_row
instead of Table#add_tr. Same with bgcolor and the like. If there
can be generic ways of saying a concept (and I can provide specific
suggestions about this after reviewing your code), then we can
provide something that can go either way without forcing people to
consider creating the same data for output more than once.

>> It should also be possible to create a generic table:
>> 
>> table = Table.new { ... }
>> HTML::Table.to_html(table)
>> 
>> I'm just thinking it would be nice if we have similar APIs. I'm not
>> there, yet, but I think this is more or less the direction that I
>> was headed.
> How about something like:
> 
> table = Table.new("PDF"){ ... }
>
> This cuts it down to one line, and lets us define a default (which
> I would vote should be "HTML").

Hmmm... won't work for me. To me, tables are generic items. They
have specific information:

  columns
  rows
  titles and headers
  formatting options
  etc.

How one *renders* those options are a different matter and is
specific to the rendering "device". The concept I'm after is a
proper Table object model with different rendering objects
available.

If this is designed right, then someone who wants to create a TEX
formatter can do so easily. One could even create a plaintext
formatter for a table that would be very easy to deal with from the
same context.

I think the confusion I'm seeing with this is that the renderer
isn't the same as the format; I'm after the format -- I've got the
renderer for PDF, and what you've got is pretty good for HTML, I'm
sure, but the renderers aren't the formats.

> Another option is to make PDF a subclass of HTML::Table. I dunno
> enough about what you're trying to do, though.

Again, that won't work -- the rendering is drastically different.

-austin
--
austin ziegler    * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.06.11
                                         * 16:07:23