[Seaside] tables

Avi Bryant avi at beta4.com
Sat Mar 22 11:17:28 CET 2003


On Sat, 22 Mar 2003, Nevin Pratt wrote:

> This is a version 2.3 feature, and I'm not running 2.3.  I felt I should
> try to understand the framework better before moving to the bleeding
> edge :-)

Fair enough, just couldn't resist sneaking that in there ;).

> I've been thinking about a simplified scheme based on Cees'
> TableGenerator approach.  Each cell of the 2-dimensional matrix (i.e, of
> the table) would have the equivalent of "Rich Text", where the text
> itself would know about it's own font, size, and style.  You create and
> add table elements thus:
>
>    table := HtmlTableGenerator new.
>    table put: myRichText inCell: aPoint.
>
> The 'inCell:' argument is a point specifying the cell of the matrix
> (i.e., the row and the column) to add the rich text to.  The table would
> look at this argument as it came in, and keep track of the current
> number of rows and columns in the table.  There would be no need to
> explicitly specify how many rows or columns, as it could figure it out
> on its own, based on what it sees in this argument at runtime.

Yes, although I can see specifying all those points getting tedious (and
not very maintainable - what if you need to insert a row?).

A long time ago Julian and I did something somewhat similar that used an
hbox/vbox layout model (actually the boxes were grids that could be
constrained to be only 1 wide or 1 high if desired).  So your table code
looked a bit like, IIRC:

Grid vertical: {
  Grid horizontal: { aCell. bCell. cCell. dCell}.
  Grid horizontal: { fooCell. barCell}.
}

This would give you

---------------------------------
| aCell | bCell | cCell | dCell |
---------------------------------
|    fooCell    |   barCell     |
---------------------------------

The tricky bit here (that you'll also have to deal with) is what those
cell objects are.  I found that mixing the programmatic html renderer
style with this kind of layout-tree-building style was difficult (in many
cases, for example, I seemed to want those cells to simply be blocks
that took a renderer as their only parameter, and that got a bit ugly).

In the back of my head, I wonder if somehow moving to a DOM-based renderer
in 2.3 will smooth some of those integration issues, but I'm still not
sure exactly how it all hangs together.

Of course, if you were really only planning on "rich text" in the cells
(and not, for example, form inputs), that would make things easier.  But:

> And, of course, elements other than rich text could also be put into any
> cell as well.

In this case I'd recommend you at least think about using #renderOn:
rather than #asHtml.

Avi



More information about the Seaside mailing list