Template mechanisms...

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Thu Dec 12 09:09:35 UTC 2002


Julian Fitzell <julian at beta4.com> wrote:
> 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).

Yes, I looked at XMLC - there are some nice webpages to read there.
Interesting approach. Someone complained about the performance of this
solution but the XMLC people claim to use a technique they call "lazy
DOM".

Interesting enough the page describing XMLC argued that the webdesigner
first build a mockup with ids embedded and then feed that into XMLC
which parses and produces the "DOM templates".

My idea that I outlined starts a bit earlier with a working system
running in Seaside/HttpView generating very simple XHTML (more or less
like today) but with id tags turned on for traceability. Given those
pages the webdesigner can start whipping it into shape and then feed it
back.

One thing needed to make this work is to differentiate between the truly
*needed* XHTML and what is just "fluff" to make it look at least
readable. Today my HttpView apps do have a little bit of "visual fluff"
in them (even though I try to use CSS as much as possible) and it would
be nice if I later - when the webdesigner has fed his "good looking
pages" back into the system - could simply "turn off" that fluff.

> > 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.

Me too. I have a collegue that likes XSL but I am trying to argue that
webdesigners don't use it and don't know how to. Not their tools either,
that's my guess of course.

I have also heard that performance is tricky.

> > 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 have had this "nagging feeling" to about it but has postponed the
issue since the apps I have been building so far hasn't been "glorified"
by anyone but me.

> 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.

I also like this approach - I really tried to learn and read up on CSS
when I designed www.bluefish.se. One thing I learned is that CSS works
very fine for some things and totally fails in other areas. The most
important area where it seems to have utterly failed is positioning. I
*really* tried to make the first page work properly using CSS
positioning but I couldn't make heads or tails of it - I was really
close but never managed to get it working the same in both IE and
Mozilla. And if I can't even do that then forget about the rest of the
browsers...

I also read on www.evolt.org that they also had to fall back on tables
for positioning. They apparently did a huge effort when redesigning
their site and making it look good in a pletora of browsers using CSS.
But they just caved in regarding positioning.

> > 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 

Totally agree.

> 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.

I have my doubts. But the idea of going with the "programmatic" approach
being able to add "tracking device ids and divs", then feeding the pages
to the designer and back and producing some kind of internal template
DOM-kindof thing and finally simply "turn off" the minimal visual fluff
that was needed from the start feels like a real cool way of doing it.
Sortof XMLC inspired but a bit more "round-trippy". :-)

The only thing I can't really see is how to handle the "component"
aspect. The webdesigner wants to work with pages (I guess) but a page
may be composed of Seaside/HttpView components of some sort. What do we
do with the glorified page when it comes back? How would the mapping be
done?

regards, Göran




More information about the Squeak-dev mailing list