Re: HtmlGenerator will improve in next version?

I would certainly second Alexandre's requests. Complex and dynamic HTML 
generation goes hand in hand with complex and dynamic server behavior. 
For example, CL-HTTP (An HTTP server written in Common Lisp, 
at http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html) has a 
poerful set of abstract HTML generating functions. The addition of 
in-place tree-based HTML generation and editing would be nicer still.

-Mark

Alexandre Rafalovitch wrote:
> 
> HI,
> 
> I was thinking what non-obvious areas could be in Jigsaw that (IMHO) should
> be improved and I came up with one, nobody mentioned anything about before.
> 
> Currently, generation of HTML is very primitive, program has to supply all
> tags and content, so creating of structured page on the fly is a bit of a
> pain and even where there is some code for creating a page as a collection
> of elements (in w3c.jigsaw.forms), those elements are not reusable or
> reparsable.
> 
> I am perfectly aware, that nice facilities for HTML creation is by far not
> the most important area of WebServer. However, I was thinking :-}.
> 
> Jigsaw is very dynamic and there would be a number of resources soon
> generating complex html on the fly a probably some filters, that would like
> to parse that html and/or add some content/metas/etc... Currently, the only
> way to do is to openStream, reparse it into new HtmlGenerator and setStream
> back. IMHO, it would be much easier if is was possible to modify html page
> in place while it is still kept as a collection of objects. Conversion of
> the tree representing the html page into the text stream which is the final
> html page would be done by Reply when it is emitted.
> 
> A simple example. A postable resource would be able to keep some half built
> form as a collection of elements and, depending on interaction with a
> client, set or reset some fields.
> 
> All of this is just my thinking and I hope somebody can add arguments for
> or against this. I know that complexity of the code to write may not be
> worth number of times this code would be needed :-{, but I hope advantages
> would be prevailing :-}.
> 
> Opinions?
>      Alex.
> 
> Ps. As my subject line shows, I am actually hoping that maybe some of the
> work is already planned into coming release, but even if it is, it would be
> good idea to discuss possibilities and problems on this list.
> 
> alex@access.com.au

Received on Thursday, 15 August 1996 17:50:40 UTC