XHTML is a tree, not a stream

Hi,

in my opinion, XHTML is best considered as a tree than as a stream. I
wonder if Seaside would benefit from a tree representation. Some ideas
come to my mind:

- it would be possible to modify a previously rendered node/tag (adding
content or changing parameters)
- #with: would not be necessarily at the end anymore (because the tag is
really closed when the tree is converted to the stream)
- Seaside would then have one representation of a document (a tree) that
can be easily converted to multiple kind of output (XHTML, LaTeX, other
XMLs...)
- there might be other advantages

One of the drawbacks would be that Seaside would not be able to send the
stream directly to the web browser while it renders components. It would
need to wait for the end. But if I remember correctly, it is already the
case.

Do you have an opinion ?

--
Damien Cassou
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Wed, 08 Nov 2006 08:59:14 +0100, Damien Cassou wrote:
There could be a #flush method which would send the partial tree to the  
browser.

/Klaus

>


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> One of the drawbacks would be that Seaside would not be able to send the
> stream directly to the web browser while it renders components. It would
> need to wait for the end. But if I remember correctly, it is already the
> case.

No, not necessarily. And it would also instantiate much more objects
and take longer as to render the tree has to be traversed in the end.

What you request was standard in earlier versions of Seaside. I am not
sure if the code is still there though, but you can easily add it
again by creating your own subclass of WAHtmlDocument.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli a écrit :
In fact, I don't need it. I was just wondering if it would be
interesting. It seems you think it wouldn't.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > What you request was standard in earlier versions of Seaside. I am not
> > sure if the code is still there though, but you can easily add it
> > again by creating your own subclass of WAHtmlDocument.
>
> In fact, I don't need it. I was just wondering if it would be
> interesting. It seems you think it wouldn't.

Well, there are certainly different approaches to generate HTML. If I
am correct SimpleWeb is using an approach where composites of tags can
be copied, stored, rendered, etc. The other extreme are templates,
where you have just a single huge string.

> - it would be possible to modify a previously rendered
> node/tag (adding content or changing parameters)

I never felt the need to do that. Rendering is a read-only phase
anyway, so you should know you whole state upfront anyway.

> - #with: would not be necessarily at the end anymore
> (because the tag is really closed when the tree is
> converted to the stream)

The problem with the #with: could also be solved otherwise, such as by
caching the block and evaluating it when the tag is flushed. However I
find it quite a nice convention to have the #with: to be the last
element, even-though this looks more like a technical restriction to
some people.

> - Seaside would then have one representation of a
> document (a tree) that can be easily converted to multiple
> kind of output (XHTML, LaTeX, other XMLs...)

The Seaside renderer creates XHTML tags. Of course you could transform
this tree to LaTeX or other XMLs, however this is certainly not
feasible in all cases. After all you can also generate LaTeX by
subclassing WADocument and directly stream LaTeX instead of XHTML by
mapping XHTML tags to LaTeX tags, this is what we did for some
commercial project a long time ago.

> - there might be other advantages

Ok, tell me ;-)

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

At PHPWebBuilder (http://sourceforge.net/projects/phpwebbuilder), we model the view as a tree. The tree is accessed through DOM messages. Changes to the tree from one request to the other are tracked. That lets us have AJAX transparently (sending only the modifications made to to the tree between each request through AJAX). The decision to use AJAX or not is just a change in the config file.

The project is being actively developed as we are using it for some projects in our company, although we are not being able to make releases, write thorough documentation or mantain the website because we don't have time at the moment.

PWB is similar to Seaside in that it is component-based and interaction is achieved through callbacks. It defers (among lots of other things) in that there is a declarative template mechanism (don't have an embedded html generation language, we use templates + DOM messages over the tree),  the view is maintained in memory, there are no continuations (back button support has to be taken care of manually), etc.

We chose PHP because we needed our applications running anywhere, but we see the limitations of PHP and the advantages of Smalltalk, of course.

Cheers, Mariano



_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside