Re:HtmlGenerator will improve in next version?

At 10:49 PM 22/8/96, Anselm Baird-Smith wrote:
>Alexandre Rafalovitch writes:
> > 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.
>
>My idea of this is the following: next release of Jigsaw will
>include some really powerful (ie extensible) server side include
>mechanism. This looks to me like a better approach then the
>HtmlGenerator approach (although the simple one present in the release
>does its job for error messages, etc.).
>

That would be a fine thing for value-added filters. Like pageCounterFilter
and other things. However this is covering case of document already written
with some editor/WYSIWYG tool. I am talking about documents that are
created on the fly by the resources themselves. It is a bit of a pain to
manually hardcode all the sequences (open tag...close tag) in all the
resources that generate HTML.

>My point is that you don't really care of the structure of the whole
>document, but what you really want is to fill in placeholders (which
>is the goal of server side include), by the results of some
>computations.

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.

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.


Alex.
Ps. Sorry for a bit confusing and convoluted response. If something is not
clear, I could try to elaborate with more details, once I know what people
are interested in discussing most.

--------| I feel as confused as a baby in a topless bar. |--------

Received on Thursday, 22 August 1996 20:47:33 UTC