FW: [Seaside] Seaside + SSP

Fri Jan 17 13:35:52 CET 2003

> True, and that's what I'll be doing as well. The template
> only needs to 
> get parsed when it changes, not on every request, regardless of where 
> it comes from. The choice of where to store the template is mostly 
> determined by work flow. I need to be able to collaborate with a 
> designer, and external templates make that easier. When I'm doing the 
> design myself, storing them in methods works fine.

Where are you storing the parse tree?  

> The advantage of keeping the template in tree form is that you can
> write the dynamic parts of the page in terms of tree transformations 
> rather than streaming html and text. Having just written most of an 
> application in this style, I find I'm very pleased with it. 
> You end up 
> with a lot less code for the interface, less coupling between the 
> presentation and the code, and more focus on the dynamic parts of the 
> interface.

If I modified SSP to actually parse the text portions of an SSP method
(as I described in another email) then I can accomplish the same
transformations because the resulting compiled code is just directly
constructing a parse tree.  If you hand it an html renderer, it would
spit HTML out on a stream (skipping the step of actually building a
parse tree), but if you handed it an HTML parse tree builder, it would
give you back an HTML parse tree.

I could even support the style of template you described (when the
method answers a node).

I actually need to do both kinds of templating and I want them to be
unified in their approach.  I need the compiled SSP style templating for
non-user editable templates, and I need an externally stored templating
system for user generated templates (which of course wouldn't allow the
directly embedded smalltalk code).

Eventually, it would be nice to support WebDAV to allow an HTML designer
to use traditional tools to access and edit the templates stored as
methods.  That I think would be the best of both world...you can use the
traditional design tools, yet keep your sources all managed with the
same system (i.e. monticello).

Do you have your templating capability in a workable state?  I think I'd
like to experiment a little and enable your templating system to be
compiled and stored directly as a method.

Such a method might look something like:

----
renderContentsOn: renderer
<html on: renderer>

<p>My name is: <span macro="className">Foo</span></p>
<p>My name is: <%= self class name %></p>
<% instvar := 'some side effect value' %>
----

Which would generate bytecodes to the effect of:

----
renderContentsOn: renderer

renderer renderingOn: self with: [  
  renderer renderTag: 'p' contents: [
    renderer renderText: 'My name is: '.
    renderer renderTag: 'span' attributes: {'macro'->'className')
contents: [
      renderer renderText: 'Foo'.
    ].
  ].
  renderer renderTag: 'p' contents: [
    renderer renderText: 'My name is: '.
    renderer evaluateAndOutput: [self class name].
  ].
  renderer evaluate: [instvar := 'some side effect value'].
].
----

So, the renderer could directly generate HTML, or it could build a parse
tree.  For externally or user defined code, we would disallow or ignore
the evaluate (smalltalk code) nodes (the parser would simply ignore the
"<%" tags).

The renderer would decide how to handle the "span" tag.  For example, it
could ignore the contents block, send #className: to some object that
has macro methods, and plug that result into its parse tree (or go ahead
and tell the node to output).  Another renderer might choose to send
#className to the receiver (also ignoring the contents) and output the
result.

- Stephen