[Seaside] Seaside2: separation between content and presentation

Avi Bryant seaside@lists.squeakfoundation.org
Mon, 2 Dec 2002 10:37:11 -0800 (PST)


On Mon, 2 Dec 2002 tblanchard@mac.com wrote:

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

Yes, I've often wondered how far you could go by formalizing this: Julian
and I have talked about a convention where each entity would respond to,
say, #listView, #detailView, #editView, #createView, with a generalized
navigation framework for finding/creating/moving between entities.  In
some simple contexts, this might be all you need.  Hmm, NakedObjects for
the web?

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

Yup, sounds very similar to the way we work.

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

Yeah, but switch components are ugly.  Is there any equivalent in WO of

  ... header ...
  html render: (currentEntity editView)
  ... footer ...
?

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

It would seem difficult for a parser to infer the abstract widgets from
the HTML, and chances are you wouldn't be able to reproduce the HTML
exactly.  However, given a decent widget library, you should be able to
look at an HTML page and build something similar very quickly.

Now all we need is a decent widget library ;).