Re:HtmlGenerator will improve in next version?

Alexandre Rafalovitch writes:
 > At 10:49 PM 22/8/96, Anselm Baird-Smith wrote:
 > PlaceHolders are most probable use for adding value in the existing HTML.
 > HtmlGenerator is a way to generate HTML. in an efficient/easy way.
 > Therefore it is two issues that are related but not the same. In my
 > original mail, I mixed those two different issues together. I will try to
 > clarify it now.
 > 
 > Issue one: Generating HTML in a resource code. That is where fancy
 > HtmlGenerator would be useful. It would allow to do nice nesting of
 > elements/table/forms/frames/Java/JavaScript without getting confused in
 > tags and opening/closing sequences. Potentially, if (when) there would be
 > significant number of dynamic resources even the saving in codebase would
 > offset the required number of classes for easy Html generation.
 > 
 > Issue two: Enhancing existing HTML. Usually this is done with filters and
 > works in the same way on both dynamically and statically generated HTML.
 > SSI would be the most obvious use. Such filters do not really care about
 > flexibility  of Html generator as far as they can easily access
 > PlaceHolders. However it is possible to write code such that resources
 > inheriting from SSI resource (or whichever way it is ) would not care about
 > the way they got the placeholder, therefore enhanced HtmlGenerator would
 > not get in a way here.

That's a clear explanation, thanks for it. As I said, I beleive
Antonio's SSIResource will cover issue one with more flexibility then
you can expect (basically you will be able to write new SSI commands
in Java).

With regard to issue 2: as I said, the original plan for jigsaw.html
was to be a full fledge package probaly along the lines that Jeeves
has (also I haven't look at it closely  yet). Your clarification
remind me of the original intent of filters. In Jigsaw's first design
(hum, it was not even call Jigsaw by then ;-) filters were intended to
provide a way to decorate emited HTML, one of the goals was to provide
an nice annotation server (run the server as a proxy that would
enhance served documents with annotations from a group of people,
for example). I had forgotten about this one.

With regard to this I would probably go the extreme way (eg use the
HTML parser that Arthur van Hoff wrote some times ago), and hack it to
make the structure editable (shouldn't be that hard, although not a
one hour project). Then you could write the annotation filter, for
example (?) Although one of the concern with HTML rewritting is that
it is pretty difficult to be SGM compliant (you don't even know, in
the case of annotations, if the document to annotate is confomrant)

 > Another issue is actually more of a problem. What happens if some filters
 > want to edit the content of the document or scan it for some sequence more
 > complex than <--!include bla -->. They would be able to do it easily with
 > dynamically generated pages represented neatly in hierarchical form, but
 > how would they do it with static HTML? Would we need Html parser? I don't
 > know if that is important issue or I am just suffering from featurism
 > syndrom. :-{
 > 
 > >
 > >I can think of some limited usage of a fancy HtmlGenerator (eg mailing
 > >list archive or this kind of apps), but I am not sure this is what
 > >people are really interested in (?)
 > 
 > If you look at Jeeves you will see they do have primitive (but more
 > advanced then HtmlGenerator) implementation of what I was talking about.
 > About people being interested. I saw two responses showing that they are.
 > There are probably more. If anybody has strong opinion for or against,
 > please let us know with examples. If it is important to significant number
 > of people, somebody (me?) will implement it.

Let's turn it this way: if someone implements something that is
usefull to others, it will be included in Jigsaw release at some
points. If it is to replace totally the current Html generator, then
it has to be as simple to use as the existing one, otherwise it can be
an "enhance" html generator sitting aside. BTW if anyone looks more
closely into this (eg writes code), then be sure to make your
generator emit code as soon as possible: one of the trouble with the
current HtmlGenerator is that it will require you to internally
generate *all* the document before you can actually send something. If
the generated doc is to be huge, this is likely to be a real
problem. (it should be friendly to Piped*Stream for example)

Anselm.

Received on Thursday, 22 August 1996 21:12:08 UTC