Avi Bryant wrote:
> 
> On Wed, 11 Dec 2002 goran.hultgren at bluefish.se wrote:
> 
> <lots about templating systems>
> 
>>Ok, Avi, Julian, what do you think?
> 
> 
> Since you ask...
> 
> I find any system that treats the template purely as text to be too low
> level - forcing me to textually insert a value or variable for every
> attribute of every form field is equivalent to writing a GUI app by making
> write()  calls to a X-windows client socket;  you might feel it gives you
> more control, but mostly what it does is make busywork and reduce
> abstraction.  This rules out the large majority of the templating systems
> out there: variable subsitution systems like WebMacro or FreeMarker,
> typical use of embedded code systems like PHP and JSP, tag-languages like
> ColdFusion - in each case, every character of the final HTML output is the
> direct result of some piece of code the developer wrote.  I
> won't even get into the evils of mingling logic and presentation that are
> inherent in most such systems, because they already fail on that basic
> principle: HTML and HTTP have very well defined structure and semantics,
> and a good templating system should know these intimately and largely
> protect me from them.

Avi and I work together a lot on this stuff so it's not surprising that 
we have generally the same beliefs.  Whether this is the reason we work 
together or a cause of the fact that we work together, I'm not sure. 
But certainly the things we dislike about existing systems are pretty 
similar.

> I know of three general approaches to avoiding this problem: parse the
> template and modify it programmatically, produce the HTML through
> (declarative) transformation of the data, or generate the HTML directly
> in code.
> 
> The first of these is the only one that's really "templating".  It's
> the approach taken by WebObjects, Seaside 0.9x, and Enhydra/XMLC (used, I
> think, by Barracuda, which was mentioned elsewhere in this thread).
> Usually this involves producing some kind of a DOM from the template,
> finding and transforming some special elements (which were given unique
> ids in the template) while leaving the bulk of the elements alone, and the
> regenerating HTML from the modified DOM.  Some systems provide better
> abstractions for this than others (Seaside and WebObjects provide
> sophisticated models of elements such as forms, links, and inputs, that
> you interact with in a fairly high level way, whereas I believe XMLC users
> tend still to directly manipulate HTML attributes), but once you have the
> DOM in memory you can obviously interact with it as abstractly as you
> like.
>
> The only example of the second, transformative approach that I know of is
> XSLT.  I've never used Coocoon or any other XSL-based system, so I don't
> feel terribly qualified to speak about them, but I don't know any
> designers *or* developers who don't shudder in horror at the thought of
> writing XSL.  If somebody has good experiences with this approach, or
> knows what the current best practices are, I'd love to hear about it.
> 
> Finally, there's the approach HttpView and Seaside2 take, which is not to
> have templates at all, but rather to generate all of the HTML
> programmatically.  As someone who's spent a lot of time implementing and
> using template systems, this seemed at first horribly backwards.  What
> I've discovered is that ditching templates entirely provides much more
> opportunity for refactoring and abstraction.  The problem with templates
> is that they force you to always think at the level of individual HTML
> tags.  Once a tag is a method, it's much easier and more natural to start
> combining them into larger and larger methods and classes, and the wins
> from this are huge.

Avi moved towards ditching templates much earlier than I.  The way he 
and I work when developing has, so far, not involved a designer and has 
resulted in us generating simple HTML with fairly minimal formatting.  I 
have held on for quite some time arguing that this is likely not the way 
that many people will end up working.

I will say that for the type of stuff we seem to end up doing, templates 
do feel largely unnecessary and reuse is definitely improved.  In 
Seaside 0.9x (and Iowa) I complained frequently about the lack of 
inheritance of behaviour and this was actually due in large part to the 
use of templates.  So working with the code generation approach in the 
base levels of Seaside2 is somewhat liberating.

I also believe in following standards and best practices as much as 
possible, so I have also been pushing for quite some time to make it 
easier to use CSS with Seaside, to try to make sure we are generating 
HTML that is strictly valid, and to use divs and CSS for layout rather 
than nested tables.  I think I have finally won Avi over in this regard 
(at least in terms of CSS... see below :) so we'll see what comes of this.

> The other thing I've discovered simultaneously is that CSS is making
> templates less and less necessary - if your code produces bare bones HTML
> that's fully annotated with divs, spans, classes and ids, the designer
> has a lot of huge amount of control over the look through the CSS file.
> Going forward, this is where I think the division of responsibility should
> lie: the programmer produces the (X)HTML, and the designer controls the
> CSS.

I believe we need to enable a web designer to do as much as possible of 
the design, because I certainly don't want to have to do it.  I am truly 
hopeful that CSS will provide enough control (along with a general 
cooperation between the developer and the designer) to do what is 
needed.  I do, however have a sneaking suspicion that it isn't quite 
going to be enough in all cases.  I think, though, that this is due 
mostly to the variations in implementation of HTML and CSS in various 
browsers.  I think most of the ugly, crazy code that designers generate 
is to workaround bugs in various browsers.  I am pretty confident that 
as we go forward and browsers begin to properly parse HTML (and soon, 
hopefully, XHMTL) and properly interpret the full range of CSS that such 
hacks will be unnecessary and we will finally be able to consider CSS 
sufficient.

[...further discussion snipped...]

Julian


-- 
julian at beta4.com
Beta4 Productions (http://www.beta4.com)