[Seaside] Against Templating -- Why?

[Colin Putney]

On Aug 6, 2005, at 11:57 AM, Steven Swerling wrote:

> Hi,
>
> I was looking through the seaside mail list archives for info about  
> templating, and I noticed in one post that the lead developer of  
> Nori gave up on templates, saying that they are "passe". Earlier  
> then that, Seaside seems to have had some form of templating, but  
> it was dropped as the html rendering system matured.
>
> Why is templating considered bad, or passe? (That's asked in  
> earnest, not rhetorically -- I was unable to come up with a google  
> incantation that would coax out an answer). The 'E' in Seaside  
> stands for "Enterprise" -- doesn't that suggest some sort of  
> collaboration among specialists?

There are several reasons I stopped developing Nori. In no particular  
order:

Templates are supposed to be about achieving separation between  
appearance and behaviour. The template supplies the appearance, the  
code supplies the behaviour. In the early days of the web, you had to  
control the HTML mark up in order to specify appearance, but now that  
CSS is mature, this is no longer the case. Today HTML mostly  
specifies the structure of the page, and the actual appearance is  
specified in a style sheet.

Building HTML procedurally has some advantages. You can factor out  
the common bits to separate methods, and bring all your favourite  
Smalltalk tools to bear on them.

I changed jobs and no longer write web applications. Since no one  
else in the community was using Nori, I didn't have any reason to  
maintain it.

> Anyway, starting with the premise that templates are bad, what  
> would be your idea of a good workflow for collaboration between  
> programmers and ui designers and graphic artists when developing  
> seaside apps? What would the tool look like that helps facilitate  
> such a workflow? Is it enough to have email and photoshop, or is a  
> more specialized tool in order?

I've never found a systematic workflow that worked really well for  
web apps. Usually it boils down to the designers producing static  
mock ups of what the page would look like when rendered, and the  
programmer writing code to generate something similar. More elaborate  
workflow systems tend to want to make it easier for the programmers  
and designers to do their work without having to communicate and that  
never works. On the other hand, with good communication, almost  
anything will work.

I'm not working with a designer these days, though. Perhaps others  
will have cool new ideas on how to marry programmer-generated HTML  
and designer-supplied CSS.

Colin