[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