FW: [Seaside] Seaside + SSP

[Colin Putney]

On Friday, January 17, 2003, at 10:35  AM, Stephen Pair wrote:

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

For the moment, I'm just reparsing the template for each request, so I 
haven't figured that out yet. But I imagine I'll use a class variable 
in the controller class. This templating system is actually part of a 
framework for the using MVC pattern in Seaside, rather than components.

This goes to your other post about wanting to support interfaces other 
than HTML. MVC provides the same sort of flexibility in a fairly 
unified framework. Templates are parsed into a tree of views, each of 
which knows how to render itself to a stream. For the html case, many 
of the views are generic TagViews, but subclasses like AnchorView and 
FormView provide special behaviour, like fetching urls from the current 
thread. For more exotic interfaces, like XUL or PDF you'd need to 
define view classes to handle the rendering.

Template syntaxes are equally plugable. I've got XML template parsing 
working, and will probably do HTML as well. I can't think of any other 
syntaxes that need to be supported, but it wouldn't be hard.

Controllers handle the dynamic aspects of the UI by implementing macros 
that transform the tree. This removes the need to embed to embed code 
in the templates, which after years of working in PHP, I really, really 
want to avoid.

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

Yes, I do think WebDAV would be a great way to handle the management of 
templates, though more as a way to automate the updating of the stored 
view trees than to integrate with source code management. I don't want 
to treat templates as code, I want to keep them as separate from the 
code as possible.

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

Yes, but only for trivial examples. I'm working on getting it ready for 
a first release.

I've snipped lots about the interaction between SSP templates and 
HTMLRenderer, which I think is going in the wrong direction. My 
objective is to divorce presentation (ie, templates) from the code as 
much as possible. Both SSP and HTMLRenderer achieve the opposite; SSP 
because it embeds code in the template and HTMLRenderer because it 
requires custom code to create the presentation. Deriving the one from 
the other doesn't alleviate either problem, it just combines them.

I know that sounds a little harsh, but I've written a lot of web apps 
in the last few years and been very frustrated by this problem. I do 
look forward to seeing what you come up with in the end. The great 
thing about Seaside2 is that it doesn't force you into any UI pattern, 
so MVC, SSP and HTMLRenderer can all co-exist nicely.

Cheers,

Colin

Colin Putney
Whistler.com