Seaside and Page Templates, Again...
By Ramon Leon - 10 October 2006 under Seaside, Smalltalk
Mark Miller has a nice writeup about Smalltalk and Seaside, a good collection of resources. One minor note, he mentions while referring to Seasides lack of HTML templates...
"They must be set up as strings within your Smalltalk code, as part of the whole Seaside application".
This isn't true at all, Seaside includes a complete domain specific language in native Smalltalk for generating HTML, there is no string handling involved. You build HTML with tags and attributes, just as you do in HTML.
Smalltalk is fully capable of expressing the same abstract syntax tree of tags and attributes that HTML expresses, so there's no need for HTML templates. Smalltalk's syntax is superior to HTML's syntax. It's not that Seaside doesn't have templates, it's that it doesn't need them.
html div class: #Header; style: 'visibility:hidden;'; with: [html span: 'Hello World']
the Smalltalk above is just as expressive as the HTML below, and far more manageable.
<div class="Header" style="visibility:hidden"><span>Hello World</span></div>
When using the Canvas API, you can write your pages, with the full power of Smalltalk's tools at your disposal. More importantly, you can do something you can't do with templates, factor your code into reusable methods, and call them. It's vastly easier to do complex layouts and more importantly, maintain them, in Seaside, than in a giant unfactored HTML template.
Comments (automatically disabled after 1 year)
[...] Edit: I had just barely gotten this posted when Ramon Leon of OnSmalltalk pointed out that I was not entirely clear in explaining myself! It is possible to do CSS programatically in Seaside, as he explains here. [...]
It's quite common, to simply include external CSS and Javascript files by adding a tag to the head. Despite Seasides ability to include CSS and Javascript as strings, that's not how it's normally done.
I let the designer work on the CSS files in the editor of his choosing, and I simply ref them, this keeps us both quite happy, I'd image most others are doing the same. When I use third party Ajax widgets, like Yahoo UI, I simply ref their external Javascript files, they aren't done as strings either.
In my case web applications are typical applications, but just with a web frontend. So there's almost no need for the seperation of developer and web designer - even if the design of the UI also needs the adequate know-how.
So I use my own rederer, derived from the standard Seaside renderer. It provides a high level interface, like windows with titles, form layout etc. Take a look at
http://www.tideland.biz/products/nbl/cards-demo.html.
In this case Seaside is extreme powerful.
mue
Yup, good use of a renderer, there's no reason every project can't have its own renderer subclass exactly for this purpose. I extend the renderer quite often myself for exactly the same kind of reasons. It can also be done with simple class extensions, if you only want to add to, rather than change how the default renderer works.
Wow. You were fast! I posted this article about an hour ago, and I had been making corrections to it.
I see what you're saying. I'm cognizant of the ability to write "html blah...blah...blah" in Smalltalk code. You are correct to point out I had forgotten that you can specify CSS in code. What I was referring to in the part you quoted was some functionality in the Seaside framework that allowed injection of CSS and Javascript into the dynamicly generated page. It allowed you to put in your own boilerplate CSS and Javascript. The tags and Javascript are not controlled by the framework in this case. Whatever method did this (I forget at the moment) took strings.
My main point was about using Mewa and Magritte in place of page templates, since they accomplish much the same thing, and might offer greater abilities than the page templates of other frameworks.
Thanks for your input.