[Seaside] Template system for Seaside + docs

Avi Bryant avi at beta4.com
Fri Mar 26 20:49:37 CET 2004


On Mar 26, 2004, at 9:29 AM, Colin Putney wrote:

> On the other hand, I don't like HtmlRenderer very much. It works well 
> with Seaside's tree-of-components architecture, which templates don't, 
> and it's a lot better than printf(), but it's still 
> code-that-generates-code, for which I have a general (and possibly 
> irrational) dislike.

HtmlRenderer works well for me, but you're certainly encouraged to 
build your own rendering class if you have a better approach.  For 
example,  one style I've wondered about in the past is a combination of 
HtmlRenderer's blocks-for-structure with a more DOM like model instead 
of a stream model.  Each node in the DOM would have a method for each 
allowed child type, that took a block, created the child node for 
itself, and then evaluated the block with it.  So instead of this:

html table: [
   html tableRow: [
     html tableData: [...]
   ]
]

it would look like this:

doc table: [:table |
    table row: [:row |
       row data: [:data | ...]
    ]
]

There are a few advantages to this.  One is that rather than the 
massive, monolithic renderer API, you get the methods split into more 
focused classes (all the variations on #tableRowWith:, for example, 
would just be on the Table node).  Another is that if you have a 
generic #add:, you can start doing stuff more functionally:

doc table: [:table |
    table addAll: (items collect: [:ea | self rowForItem: ea])
]

rather than passing the renderer around everywhere.  Also it might be 
useful to have the objects for the individual nodes around in some 
cases, like to query them further down the tree.  The obvious 
disadvantage is that you have all these extra block params cluttering 
things up.  It also uses some extra memory but that's not likely to 
matter.

Anyone feel like implementing that?

Avi



More information about the Seaside mailing list