Dynamic CL-HTTP Output Generation
The current version of this site is implemented statically using tables:
- Each page is a table of two rows: a heading line (one item) and
a pair of items.
- The second row is a navigation table and the real "contents" of
It has been suggested that we provide output tailored to different
needs or preferences: tables, no tables, frames, etc. The author of the
current site has also noticed that it is difficult in the current
static implementation to maintain navigational cues as new pages are
added, or as the design of the display of navigation cues is changed.
It is proposed that the dynamic serving capabilities of CL-HTTP be
used to address both these issues. The author of this plan (firstname.lastname@example.org,) does
not have access to CL-HTTP, so better ideas are solicited! Perhaps
someone has done all this already?
The idea is that the basic contents of the pages are stored in text
files, and the server keeps a database of what files are known, what
groups these files belong to, and some information about the groups.
Pages and navigational displays are then dynamically created to meet
the various preferences.
Throughout this proposal, pages are refered to as being created
dynamically. For performance reasons, these might actually be created
once and cached, but this does not change the model.
Here's the proposal:
Here are some related issues:
- The "contents" of each current .htm file is copied to
a .text file of the same name. These consitute the "known pages".
- The server has an ordered list of areas. Each area has a name, a
color, and an ordered list of known pages. Each page has a title and
the name of the .text file that holds its contents, and possibly
another ordered list of known pages.
- A welcome page gives the option of using forms, tables or simple
(i.e. non-tables, non-forms) pages. Selecting the tables or simple
format brings up a specialized table/contents.htm or
simple/contents.htm page. Selecting the frames format brings up a
frameset which defines a narrow navigation frame on the left and
displays frame/contents.htm on the right.
- There are three abstract URLs defined for each "known page":
- table/file.htm displays in the same format as is
- frame/file.htm keeps the current navigation table in a
separate frame, allowing the contents to scroll independently.
- simple/file.htm displays the contents without tables, but
adds a simple horizontal navigational bar at the top and bottom of the
- There are three filters defined that convert general html to the
appropriate specialized contents. The only specialization currently
required is for anchors:
- The URLs of "known pages" must be translated to the appopriate
simple/file, table/, or frame/ URL.
- The frame filter must add the "display" target for "known pages"
and the "_top" target for all other HREFs. It must also add an onClick
the navigation frame with the correct information.
- There is a navigation bar generator that generates the
appropriate html based on the format and the "known page" being
displayed. The frame and tables format use the same table style
currently used, while the simple format uses a three line format
corresponding to the general links, area listings, and pages within
the current area of the current format. The generator uses the
database of pages and the current page to determine:
The generated contents are passed through the formatting filter to fix
up the "known page" HREFs.
- The links used in the up, forward and back arrows.
- The current area, to be displayed in bold.
- The listing of other pages in the same area, with the current
page in bold.
- It seems likely that the the W3P presentation system should be
used. A NAVIGATION-BAR presentation type would be defined, with
specialized methods for SIMPLE, TABLE, and FORM views.
- It is mentioned above that for performance reasons, it may be
desirable to cache a static snapshot of all pages. It may be
desirable to do this for other reasons as well. People without
CL-HTTP serving capabilities might want to make a mirror of the site.
A static snapshot would facilitate this. One possibility is to
provide an update snapshot function that uses W4 to create not only a new
static version of the site, but .tgz files as well.
- The welcome page gives us a place to display pointers to other
non-English language versions. The structure also makes it easy
to create foreign language versions - provided they either also use CL-HTTP
or make a static mirror.
- This scheme also makes it easy to generate a static content-only
version suitable for printing.
- In the non-simple versions, it would be nice if the navigation
bar had a pull down menu for each area that showed the pages within
that area. Perhaps this could be done by making the navigation bar a