[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