Pascal Bourguignon wrote:
>
> In another package, I defined DEFELEMENT and DEFATTRIBUTE otherwise
to
> generate an HTML parser. Since the knowledge of the tags and
> attribute is embedded inside WITH-HTML-OUTPUT, I feel it's a solution
> that's less declarative, ie. lower level than mine and less useful.
WITH-HTML-OUTPUT doesn't really have any knowledge of anything except
how to decide if a form is markup or Lisp, so it can know whether to
transform it. It's not designed to enforce some DTD or anything like
that. In fact even its knowledge of what is a tag or not is
parameterised - there's a (compile-time, since it's a compiler not an
interpreter) predicate which you can use to decide if something is a
tag or not.
> Also, since HTOUT binds locally an output stream, and doesn't take it
> as argument to the non function keyword tags, I don't see how you
> could split the description of a page over serveral functions.
Simply pass down the stream in the ordinary way. If that's too much
work bind a special variable to the stream and write some wrapper
macro.
> On the
> other hand, for now I have to use a global context to generate HTML,
> but this allow be to define methods to insert items on pages such as
> headers, feets, forms, etc. This could be easily done with Andreas'
> solution. Would HTM work outside of the lexical context of
> WITH-HTML-OUTPUT?
No, but why should it - simply wrap it in a WITH-HTML-OUTPUT form
either passing the stream or using some special. WITH-HTML-OUTPUT
doesn't imply `generate a whole page' or anything, it just marks the
parts of the code which the HTML compiler should look at.
--tim
Notes (1) I'm the author of HTOUT, so I may be biassed
(2) The version at www.tfeb.org is really old due to some
screwup on my part - I will replace it with a somewhat more
modern one. The main difference is that the more recent one
does a much better job of detecting compile-time constant
HTML and generating the output at compile time rather than
run time.