HTML-table

ruby-talk
1

Austin Ziegler wrote:

Daniel,

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?

I’m thinking:
require ‘html/table’
# Create a table
table = HTML::Table.new { … }
# Create a table row
row0 = HTML::Table::Row.new { … }
table.add_row(row0) # or table << row0
# or table[0] = row0

I originally was going to make Row a subclass of Table (and Data a
sublcass 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…

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

> table[1][1].configure { ... }

Yep, like that idea, too.

# Finally, print the table

puts table.to_html

Many of the output options that you have are similar to what I need.
Note that for HTML4.01 and later, you need a Table::Header and
Table::Body as well – the body can contain rows as well.

See “Future Plans”. :slight_smile:

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”).

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

Regards,

Dan

2

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