[Seaside] Seaside + SSP

Stephen Pair seaside@lists.squeakfoundation.org
Thu Jan 16 21:53:55 CET 2003


I definitely think some approach to templating is needed.  One thing
I've been thinking about is coming up with a flexible markup approach
that isn't HTML at all.  It would look something like:

----
renderContentsOn: html
<ssp on: html>

<paragraph><title>My name is: <%= self name %></title>
<paragraph><content>Some content</content>
----

This would yield bytecodes to the effect of:

----
renderContentsOn: html
	self paragraphOn: html.
	self title: [
		'My name is: ' sspStreamOn: html.
		self name sspStreamOn: html
	] on: html.
	self paragraphOn: html.
	self content: ['Some content'] on: html.
----

This way, the receiver's methods would determine how a paragraph or
title is actually rendered into usable html and you could utilize the
ordinary SSP style templating.  The would allow specialization of these
things by class, and the markup tags are limited only by the methods
your class defines.  I haven't quite worked out how to pass around the
html stream...perhaps the methods would be #paragraphOn:, title:on:,
content:on:, etc.

I'm really after an effective templating mechanism without embedding too
much formatting knowledge directly in the templates.

- Stephen


> -----Original Message-----
> From: seaside-admin@lists.squeakfoundation.org 
> [mailto:seaside-admin@lists.squeakfoundation.org] On Behalf 
> Of Avi Bryant
> Sent: Thursday, January 16, 2003 4:41 PM
> To: seaside@lists.squeakfoundation.org
> Subject: Re: [Seaside] Seaside + SSP
> 
> 
> 
> On Thu, 16 Jan 2003, Stephen Pair wrote:
> 
> > This of course bypasses the formatting supplied by the 
> > WAHtmlGenerator, which would eliminate the possibility of 
> re-directing 
> > the render method to some non-html output.  What would be 
> really cool 
> > is if we could make a parser that would parse the HTML (or other 
> > markup) in the SSP method and spit out bytecodes that call 
> methods on 
> > the HTML generator.  Then you could conventiently write rendering 
> > methods in marked up text, yet still be able to re-direct 
> output to a 
> > different markup language.
> 
> Yeah, I played with something like that at one point (not 
> generating bytecodes directly, just doing a source-to-source 
> transform).  The problem is that the interesting part is not 
> HtmlGenerator but HtmlRenderer, and so you have to find ways 
> of representing things like anchorWithAction:text: in the 
> html.  But I still think it would be a decent way of adding 
> templating to the current system.
> 
> I've also been doing experiments recently with replacing 
> HtmlGenerator with an HtmlBuilder class, that has the same 
> interface but generates a DOM tree instead of directly 
> printing to a stream.  Surprisingly, it doesn't end up being 
> measurably slower (even after rendering the tree down to 
> HTML), though it definitely creates more garbage.  My guess 
> is that this might allow more flexible templating approaches...
> 
> _______________________________________________
> Seaside mailing list
> Seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
> 




More information about the Seaside mailing list