Machine-editable DOM/sexpr model specifying HTML output to be generated?
- From: jaycx2.3.calrobert@xxxxxxxxxxxxxxxxxxxxxx (Robert Maas, http://tinyurl.com/uh3t)
- Date: Fri, 08 Aug 2008 19:56:32 -0700
I'm currently planning work on a project for a CGI/CMUCL
application, where I would like to build a data structure
representing the parse tree of HTML output, i.e. a DOM
(Document-Object Model). But rather than build all the pieces
bottom-up and put them together at the last moment, I want to build
an editable DOM, which starts out with a generic ABORT message
which is later replaced by either a more specific ABORT message or
a specific user-error message or normal valid output or a mix of
normal output and a user-error message. I'll have a toplevel CATCH
and/or CATCH-ALL-ERRORS around my entire application, and if
anybody ever throws to that CATCH then the DOM will be quickly
patched to include something expressiong the parameter to the THROW
or ERROR, and the the entire contents of the DOM after that edit
will be sent out immediately.
The purpose is to allow abort (deliberate, or due to program bug,
it shouldn't matter which) at any time in the middle of a
HTTP/CGI/CMUCL transaction to be handled by a single unified
mechanism, thereby establishing failsafe operation in all cases.
And to unify the code, normal successful program termination would
share the same code, somewhat analagous to the way the Unix shell
treats return code of 0 to indicate successful return from
application but no matter whether there was an error or not there's
exactly the same graceful return from the application to the Unix
shell.
Before I go on, does my purpose (second paragraph) sound reasonable
and obtainable, and does my proposed mechanism (first paragraph)
sound like a reasonable way to achieve the goal implied by the
purpose? Or is there a better way to think this through?
In all my CGI applications to date, I have functions that I call to
generate HTML output to standard output live at the moment I call
the HTML-generation functions, which are buffered by the Apache
server until my application quits. Unfortunately this makes coding
tricky for dealing with deciding whether to generate text/html or
text/plain output, since the header for that must be generated,
hence that decision committed, before my program reaches any point
where subsequent output might be generated. I hack my way past it
by keeping a flag as to whether the HTTP header has been generated
yet, and on ABORT I generated the header if it wasn't yet
generated. I would like *NOT* to continue that tradition in my next
major CGI application, hence my thinking about the editable-DOM
method as an alternative.
In recent years I've seen mention of various sexpr syntax for
representing the structure of HTML files, which may be used by a
parser or by a generator. It wasn't clear to me which of these
open-source and other software packages allowed editing within a
structure and which allowed *only* bottom-up building of structure
with no further editing supported. So my purpose in posting today
is to ask anyone with experience with any of those packages to
please identify the name of the package you know about and tell me
how well the package supports automated editing to build from a
skeleton abort message towards the final DOM product just prior to
translating to actual HTML text. I.e. how suitable is each
HTML/DOM/sexpr package for my intended use.
Names that I recall for file-extensions on static DOM/sexpr pages
that trigger automatic translation to HTML are .LHP (analagous to
PHP) and .LSP (analagous to JSP and ASP). The one that most
appealed to me was one that used (in CAR position of sexpr) keyword
symbols for HTML tags, such as (:B "This text is bold."), and
ordinary symbols for Lisp fuctions to call to generate the sub-form
to insert at this place in the overall expression, such as
(FORMAT "~&The current time is ~D seconds since the era began.~%"
(GET-UNIVERSAL-TIME))
But since those discussions were about static overall Web pages
that just happened to be expressed in DOM/sexpr form instead of
SGML/XML form, and allowed small pieces to be generated by live
Lisp code, there wasn't any discussion of the ability to build such
a structure in a Lisp core-image by multiple edits until it's all
finished and ready to convert to HTML, where Lisp could could
traverse the *entire* DOM structure instead of only work with the
tiny place where the code was embedded. Of course I suppose
somebody could "cheat" by wrapping a DOM-editor around the entire
document, or around a failsafe stub, like this:
(MAIN-EDITOR '((:HTTP "text/plain")
(:HTML (:HEAD (:TITLE "Abort"))
(:BODY "Some unknown fatal error happened."))))
MAIN-EDITOR could then do whatever edits were required per my idea.
But unless the DOM software had good utilities to support finding
the desired place in the structure to do each edit, it would be a
bear to write the code for MAIN-EDITOR.
So I'm asking if somebody has experience with hacking one of those
packages as summarized just above, or whether any of the packages
actually *supports* my overall design in a non-hackish way.
In particular, one of my ideas if I needed to write the whole thing
myself, "re-inventing the wheel", if none of the available packages
can do the job reasonably, is that various places in the structure
would have a continuation tag in the CDR of the last cell in the
level of list, which would be replaced by NCONCing more statements
at the same level followed by that continuation tag at the new end.
Thus (:BODY . :BODYMORE)
might later be spliced to read
(:BODY (:H1 "My DOM Hello World attempt")
. :BODYMORE)
then later:
(:BODY (:H1 "My DOM Hello World attempt")
(:P "First line of test paragraph."
. :PMORE)
. :BODYMORE)
then later:
(:BODY (:H1 "My DOM Hello World attempt")
(:P "First line of test paragraph."
"Testing 1 2 3 ... infinity!"
. :PMORE)
. :BODYMORE)
then later:
(:BODY (:H1 "My DOM Hello World attempt")
(:P "First line of test paragraph."
"Testing 1 2 3 ... infinity!"
. :PMORE)
. :BODYMORE)
then later:
(:BODY (:H1 "My DOM Hello World attempt")
(:P "First line of test paragraph."
"Testing 1 2 3 ... infinity!"
. :PMORE)
(:P "Heres's a second paragraph, just one line, all done already.")
. :BODYMORE)
then if that form as it stands there is suddenly submitted for
conversion to HTML, all the continuation tags are immediately
flushed first, so this is the form that gets converted to HTML:
(:BODY (:H1 "My DOM Hello World attempt")
(:P "First line of test paragraph."
"Testing 1 2 3 ... infinity!"
)
(:P "Heres's a second paragraph, just one line, all done already.")
)
But maybe one of the existing HTML/DOM/sexpr packages has a better
idea for making it easy to edit a growing DOM as the application
computes more items to insert into it various places?
.
- Follow-Ups:
- Prev by Date: Re: Do You Miss Hearing About Cells All the Frickin Time???
- Next by Date: Re: Do You Miss Hearing About Cells All the Frickin Time???
- Previous by thread: Do You Miss Hearing About Cells All the Frickin Time???
- Next by thread: Re: Machine-editable DOM/sexpr model specifying HTML output to be generated?
- Index(es):
Relevant Pages
|
