[Seaside] Seaside2: separation between content and presentation

[tblanchard@mac.com]

On Sunday, December 1, 2002, at 11:03  PM, Alain Fischer wrote:

> But I wanted to know the vision of all seasiders about separation 
> between content and presentation.
> When I make a web site for a customer, the common way to proceed is 
> that I receive an html prototype
> of the pages I must generate then I transform them using the 
> webObjects tools in templates.
> It's easy if the templates are not organised too hierarchicaly, 
> otherwise it could be difficult.

Yeah, I get that sometimes - the other way is to do it from back to 
front - each business entity likely needs 3 views created for it - a 
quick line view for picking from a list, a detail viewer, and a form 
for entering attributes for a new one (also used to edit an existing 
one).  The last two are often the same object with conditional html 
replacing fields with labels.

Then there's a css sheet done for styling and a bunch of task oriented 
pages are done which just incorporate these views in a higher level 
application structure.

> Has I see it, there is multiple way to do this:
>
> 1) Using the templates of seaside0.94
>     + very near to WebObjects, easy for simple templates
>     - hard to do when the templates are hierachical.

No sure about this.  I just did a WO forms builder that uses lots of 
switch components for rendering various kinds of components in a higher 
level layout.  Its pretty complex but the parts are highly reusable.  I 
also had the unhappy situation of needing to use single table 
inheritance in my entity model - this approach worked really well for 
helping me cope.

> 2) Using XML/XSL style sheet (transformation could be on client 
> browser or on the server side)
>      + w3c standard
>      - not well supported on browser, authoring tools and web designer.

Probably my last choice.  I find XSL impenetrable and essentially 
write-only.  So do the people I work with.

> 3) Converting html page in HTMLGenerator code
>     A way to explore. Perhaps coupled with the refactoring browser to 
> cut one page in hierachical component.

I quite like the idea of this one.  I'd definitely prefer to work with 
a widget set that happens to render to html.  If such a parser build 
more abstract widget views I'd be quite happy.