[Seaside] Template system for Seaside + docs
Colin Putney
cputney at wiresong.ca
Fri Mar 26 21:47:52 CET 2004
On Mar 26, 2004, at 2:49 PM, Avi Bryant wrote:
>
> 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.
Well, that's what Nori is, more or less. ;-)
> 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:
This I like. In fact, this style is very reminiscent of Nori's view
hierarchy. The API is more elaborate, of course, since it's designed to
be used directly instead of driven by a template parser, but the gist
of it is the same. I bet components built on top of this API would be
as testable as Nori controllers.
One way to tackle this is a refactoring of Nori - the templating part
would end up being a very, very thin layer on top of the DOM renderer,
and only necessary for those really odd situations where you really do
need a template.
Unfortunately, since I don't write web apps for a living anymore, I'm
not terribly motivated to put in the effort. I've got plenty to chew on
with OmniBrowser.
Colin
More information about the Seaside
mailing list