HREF Considered Harmful

Comment on Where are the templates? by James Robertson

I'd caveat that this way - technically, you are likely correct. Marketing-wise, I'm less sure. If I were you, I'd have template support as an easy thing to use in Seaside, simply as a way of making it look less threatening to the shops that rely on web monkeys for all the html design.

On the one hand, agree there's alot that gets done with templates in web apps that could be better delegated to CSS. On the other, when I see some displaying tabular data in a web page, using list tags, I think they've missed the point. HTML is declarative (reading it makes sense) and a success thanks to the "View > Source" factor as well as allowing "broken" web pages to work, thanks to browsers often being smarter than web page authors. Would the WWW have taken off if we'd begun with XHTML and browsers that choke if a page is badly formed? CSS often detracts from the "View > Source" factor. CSS, IMO, also appeals to the techie obsession of doing things the "Right Way" (an obsession that often puts projects at risk), much like developers who, when writing, say, a Guestbook app for a web site, begin with developing a database abstraction layer. Personally think there is a value in imperative template engines (e.g. PHP, Perl/CGI), for quick and dirty solutions as well as component oriented template engines, such as ASP.NET or JSTL (minus the imperative tags) to extend HTML's declarative nature. Personally think;

James, frankly, if I were interested in that kind of marketing, I'd have written Seaside in Java. Dick Gabriel taught me the phrase that Lisp folks use for that: "helping losers lose less". This isn't about naive idealism or arrogance - I'm very pragmatic (or I wouldn't be using HTTP/HTML at all), but I'm only interested in making compromises that have real technical utility, not those that have perceived utility by those that don't understand the tech. If I'm going to be doing marketing, I want to believe that what I'm hyping really is the best way of doing things, not just the most popular. I'm not really selling a product, so I can get away with that.

Harry, I don't really understand what you mean about "view source". To my mind, having clean, semantic HTML makes viewing the source a pleasure - it has only the content and none of the style cruft. That's part of the point - that when using a PDA or a screen reader you get as simple a page as possible. And you can always view source on the stylesheet if you want to know how some visual effect was done.

I agree that using lists to do tables is "missing the point" - if you have tabular data, clearly it should be in table markup. The example I linked to was more of a cute "look what I can do" than anything else, I think (although being able to output the data in column order instead of row order is interesting).

As for choking on invalid XHTML, I don't think anyone's arguing that browsers should do that. I'm certainly not.

One should not use the CSS Zen Garden as an example of how CSS can magically transform simple, semantically-focused markup. The XHTML for the site is crafted to provide numerous hooks for the CSS. There are divs, spans, ids and classes that exist mainly to provide a rich scaffold for fancy CSS. For most Web sites, the markup could be the same. But if you want to do certain clever UI things you'll need to think through adding or changing divs, spans, etc, as well as which and how many class values to use. A common piece of code to emit markup will not serve these cases.

James, that's a good point. IIUC, a lot of the extra spans in the zen garden are unnecessary with some of the new image-replacement alternatives to FIR. But you certainly need lots of classes and ids to give CSS the right hooks; providing these is the main concession a developer should have to make towards design (and yes, there may well be cases where a designer needs to ask a developer to add one especially to support a certain look, but that's not the end of the world IMO).

At the MFA trial run, it was interesting to compare Seaside with my own "Fred", which was basically just a plug-in for Struts for generating XML and applying XSLT in place of the JSPs. Rather than creating another template language, or using one of the existing but marginal ones, the choice of XML and XSLT allowed for a very simple implementation and re-use of existing libraries and experience. If there are XML and XSL parsers for Squeak, the simplest thing to do to satisfy the demands for templating could be to generate XML and allow them to be transformed. Of course, throwing all those buzzwords at Seaside would probably make Avi flip. But since XSLT is a fully Turing-complete functional-style language, it should be quite straightforward for Lisp people -- if they can get over having angle-bracketed identifiers in place of parentheses.

Steven, I wondered if XSLT would come up. Here's my take: it's a given that I have some domain objects that represent the data I wish to display. It's a given that this data needs to eventually end up as HTML. So what's the benefit of objects->XML->HTML over objects->HTML? Even assuming the (unrealistic) situation where the objects->XML stage takes no extra work on the part of the developer (say you have a really good automatic XML serialization scheme), you're left with two competing ways of generating HTML: in the one case, writing Smalltalk/Java/whatever code to transform a rich object model into HTML, and on the other hand, writing XSLT to transform XML into HTML. I can't in all honesty think of a single advantage of the latter, but I can think of lots of disadvantages: no encapsulation, not much abstraction, atrociously verbose syntax, no development environment support. If it's the extra indirection that interests you, it's easy to add this at the object level - you can go objects->objects->HTML just as easily as objects->XML->HTML. If it's some notion that "the designers can write XSLT", I'm guessing you haven't tried this in real life. Maybe I'm being dense here, but what's the appeal?

You are absolutely right, Avi, that objects->XML|XSLT|->HTML doesn't really gain you much. In fact the only particular point I really wanted to make is one about using what's already available. If people insist for whatever reason that some sort of templating is really necessary, why create yet another markup language? At least with XML/XSLT there are tools like XMLSpy that I can say cite real experience with web designers using successfully. Certainly if tool support and web designer usability are the issues, then a custom one-off design isn't the way to go. At time I saw Seaside I was skeptical about the capabilities of CSS to really do all the formatting. I have learned about bit more about CSS 2.0 and I think that going from simple HTML and using CSS will probably work for many typical websites. Since XHTML is a subset of XML, in the sense that it's tags that are strictly syntactically correct and valid, there might be a case made for using a simple XSLT to "enhance" the generated HTML with appropriate hooks for CSS. On the subject of language support for serializing objects to XML. If generating XML from an object tree is as simple as a Visitor pattern to apply object.serialize() to the entire graph, then generating other representations via XSLT, XHTML or PDF or whatever, becomes a better option. I mention this last one because of a specific experience I had with a business application generating both HTML and printed statements via XML/XSL transform from business objects. If you have no use case for multiple representations, there's no win.

Three observations (my 6 cents ?): Building up the HTML in the code makes it impossible to: (1) Use normal page design tools (also rules out some template schemes) (2) Utilize many Web/UI people who don't know code The X(H)TML presentation can be linked to the domain model by attributes that refer to ids or domain model instance variables e.g. Amrita in Ruby does this fairly nicely. If browsers implement CSS and XForms, better to generate (1) XML of the domain data (2) XForms for interaction (form) elements (3) CSS for styling both the above Using today'a CSS tricks like

• to encode Menus is bad because (1) you have lost information (2) hard to even consider non-browser front ends The last point leads to a question I have: it seems Seaside's real strengths with Continuations (modeless interactions, exploited specifically in the browser Back button), and composable Components that include UI interactions and application logic, are both useful outside of web apps. Have you considered whether a bit more decoupling of the html/http/browser assumptions might make it possible to "Render" onto very different user interfaces? If you built up a somewhat more declarative decsription of "Interactors" rather tnan generating HTML, could it allow a Renderer to split an Interaction across multiple pages, or batch them up into a richer-client interaction by pushing the whole thing across along with some Javascript (with less server round-trip), etc? Great work!!!

Sophie,

The whole point of keeping the HTML simple and semantic is that you don't need a tool like Dreamweaver or GoLive to create it - those should only be used to build the stylesheet. One thing that will be interesting as standards-based design gets more popular is to see how tools like that evolve to keep pace. I think you want a very different kind of tool - it's like the difference between typesetting with Word and with LaTeX.

As for using Seaside's model for non-web applications, that's a little tricky: I can certainly see it working with a web-like client that has a slightly thicker layer (XUL, for example), but too much of its design assumes some of the peculiar properties of the web browser as an interface: that the UI spec is regenerated in full each time, that events happen in transactional bunches, that backtracking and forking paths is supported naturally by the client. You might be interested in this paper, though: http://citeseer.ist.psu.edu/552421.html.

Avi, Is the seaside tutorial (http://www.beta4.com/seaside/tutorials/tutorial1.html) new? If so, does it reflect that you are moving seaside towards a template approach to html generation? I like the template style and the connection back to the Smalltalk (except I would have uniformly used an "id"-like attribute for everything, including methods).

No, that's an ancient tutorial for the 0.9x versions of Seaside. Ignore it.

It surprised me to see you implying the need for an additional layer of XML in order to use XSLT. Aren't you already outputting XHTML with semantic markup? It seems like adding a simple transformation layer on top of that would be all you would need to do.

The argument for is mainly this: in my experience there isn't one particular semantic structure that really allows you to lay things out any way you can imagine with css (even CSS2, much less the current state of browser support). Even the Zen Gardens example, which admittedly has lots of markup specifically for layout and which in semantic terms can only be considered cruft, is going to limit you from taking certain design paths.

So adding a layer on top of your semantic markup that can provide a little bit of design hooks where needed and gets out of the way the rest of the time could make a lot of sense as the range of differing display needs grows.

A related fact is that your audiences may want different views of the data that your implementation model didn't anticipate. Are you going to write classes to generate RSS in addition to your XHTML output? Or XSLTs to do it? I suppose the answer could vary... I can certainly imagine scenarios where using XSLT might make a good deal more sense.

Nathan, that's the most cogent argument for XSLT I've heard: a way to give designers an extra tool for manipulating the semantic HTML generated by the developers. If I were working with a designer who was comfortable with XSLT and wanted to use it that way, I guess I'd be fine with that. In most cases, however, I would expect that

• it would be very unusual to find someone who was both a great designer *and* was willing to touch something like XSLT with a ten foot pole
• even given the above, it would almost always take less time for the designer to ask the developer to tweak the Smalltalk code genearating the markup than to write a transformation to do it.

One of our needs is for the markup to come back from the 2nd-tier objects in possibly several markups, HTML for browsers, XML for b2b, WML, etc. Thinking simplistically, could there be methods like WAComponent>>renderXMLOn: or WAComponent>>renderWMLOn: Of course, in my newbie-ness, I may be missing existing solutions.

Bill

By dividing your audiences into two categories, "designer" who is responsible strictly for graphical presentation, and "developer" who wrote the application and can presumably add classes and methods at will, I think you leave out an important potential role, and it's one I find myself in quite frequently.

This is the role of highly technical user/configurer. The actually abilities I may have to do things within the system may be the same as that of the developer who wrote the application, or I may have a subset of those. However, my approach and inclinations are much different from those of the developer. To facilitate designers and the business side to get what they need out of an application, I am looking for an API I can use to manipulate the application without having to re-write it. One way this API can be presented to me is by way of XML output that I can transform using XSL. One advantage to having an XML output and XSLTs is that I can treat the system you wrote as a black box and stay with a relatively easy to interpret output layer (the XML output) and a familiar transformation layer (XSL).

As applications acquire larger numbers of output types, they often end up with an abstraction layer sometimes referred to as "skins". You could abstract the "skin" of the application as a set of XSL templates. You could also abstract it as a set of smalltalk classes, or use another templating system. As you may have guessed, I would be inclined to argue for XSL so that people with that skill set have an easier learning curve. If your target audience doesn't have the XML/XSL skill set, than another choice may be more appropriate.

I can totally understand your distaste for XSL, I've coded with it enough to have ample frustration for its weaknesses. However, I have also experience situations where the XSL paradigm fits like a glove, and I can scarcely imagine a better technology for the particular niche it inhabits. I suspect your application may have such a niche hidden away in it.

But shouldn't we really store and represent the visual aspects of every application in terms of the cognitive rules of association, feeling, and understanding? ...
An API of "intended effect on the mind" rather than rules of "mechanisms and algorithms"?
Something more likely found in a designer's textbook than in software whitepages?