[Seaside] Against Templating -- Why?
cputney at wiresong.ca
Sat Aug 6 19:17:33 CEST 2005
On Aug 6, 2005, at 11:57 AM, Steven Swerling wrote:
> 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
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
> 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.
More information about the Seaside