The user interface in the DLXS middleware is realized by a combination of interrelated techniques:

• HTML Templates
• Processing Instructions
• ProcIns Module

HTML Templates

HTML templates are used to deliver dynamic content from the CGI within a prescribed HTML structure. In general, there are as many templates per class as there are distinct page types in the overall functional architecture of the class. A collection implemented with the TextClass middleware, for example, can include up to 33 template files for delivering, among other pages, multiple search forms, results displays, bibliographic headers and tables of contents, search histories and full text displays. Each HTML template is a combination of static HTML code for areas of content that are unchanging from page to page, and processing instructions that are either replaced by content provided by the CGI or used to remove content or code from the template before delivery. Processing instructions can deliver simple strings, or large combinations of text and HTML code, depending on the circumstance, but the practice has been to minimize the amount of HTML code replaced via a PI because this allows for easier maintenance of graphical interface at the template level. Otherwise, the only rule governing template planning is that, when parsed, it should deliver valid or acceptable HTML to the browser.

Fallback Mechanism

DLXS employs a fallback mechanism to determine whether to use the default templates, javascript files, or graphics. in DLXSROOT/web/c/class or to prefer a custom template in DLXSROOT/web/c/collection or DLXSROOT/web/g/group. This mechanism allows individual collections or collection groups to have an appearance different from the default. Currently the CSS files do not participate in this mechanism.

There is enhanced template debugging available via the debug=tpl URL parameter. Here's the basic idea of how fallback works:

1. If the URL has a tpl= parameter the filename specified as its value is searched for according to the fallback rules outlined in 2. through 5. below.
2. If the URL has one 'c' parameter the mode is "singlecoll" and the fallback is
   1. collection webdir
   2. default group webdir
   3. class webdir
3. If the URL has more than one 'c' parameter the mode is "colls" there is no fallback: always use the class webdir
4. If the url has a 'g' parameter and no 'c' parameters or a 'g' parameter and more than one 'c' parameter the mode is "group and the fallback is:
   1. group webdir
   2. class webdir
5. If the URL parameter has a 'g' parameter an *one* c parameter the mode is "groupcoll" and the fallback is:
   1. collection webdir
   2. group webdir
   3. default group webdir
   4. class webdir
6. Allows the g (group) parameter to "ride along" with the c (coll) parameter to allow a logical branch if the 'xc' (cross-collection) parameter is set
   • If the 'xc' parameter is set the situation is one where the user was in a multiple collection environment such as a group selection page listing several collections but just selected one collection to search. So we want to use the group templates. To accomplish this, if 'xc' is set on the URL, Collection Resolution changes the mode from "groupcoll" to "group" (case 4.) so fallback will select group templates, if available.
   • If the 'xc' parameter is not set the situation is one where the user was in a multiple collection environment such as a group selection page listing several collections but navigated to a single collection home page to focus on just one collection. Here we want to use collection templates and fall back to the group templates if no collection templates are available. The is accomplished by leaving the mode as "groupcoll" (case 5.).

Finally, there is support for the "defaultgroupid" field in the database on a per collection basis for all classes. This lets collections participate in a default group to acquire templates in the absence of either collection templates if in "singlecoll" mode or collection or group templates if in "groupcoll" mode.

Processing Instructions

HTML templates are combined with processing instruction tags that are parsed and replaced by the middleware. Processing instruction tags are of the form

<?PI_IDENTIFIER_NAME [modifiername="value"]*>

where all identifier names are preceded by a question mark and are represented in all capital letters with underscore characters. Zero or more modifier name/value pairs can be included to provide additional parameters. Here are two example PI tags:

<?TITLE>	Appears witin <TITLE></TITLE> tags and supplies a collection title string.
<?DOC_ROOT mode="single">	Can appear within the href or src attribute values in individual collection templates to return the appropriate local root path of that collection.

Processing instruction tags are not, in all cases, a standardized API mechanism to collection information, though they share some of those characteristics. In general, the PIs are more likened to a customized API to the middleware itself. In this regard, PIs perform two general types of functionality:

PIs may act as simple variable names: As in <?TITLE> above, replaced by simple strings or even large blocks of HTML code and text;

PIs may act as include/exclude instructions: A pair of PI tags may instruct the middleware to include or exclude code contained in the template, depending on specific context.

<?INCLUDE_COLL_SPECIFIC_CONTENT id="navbarbrowselink">

<td id="browsetab" width="90" height="23" align="center" nowrap>
<span class="navlinks">
<a id="browselink" href="<?COLL_SPECIFIC_CONTENTid="navbarbrowselink"cginame="text-idx">" class="nav" onMouseOver="P7_autoLayers(0)">Browse</a>
</span>
</td>
<td id="sep3" width="1">
<img src="/t/text/graphics/plug.gif" width="1" height="1" border="0" alt="design graphic">
</td>

<?INCLUDE_COLL_SPECIFIC_CONTENT id="navbarbrowselink">

The code example above is from the table that contains cells navigation bar tabs and tab divisions. The HTML wrapped within the <?INCLUDE_COLL_SPECIFIC_CONTENT> PI tags is for a browse feature that is not supported by all collections. The PIs are used to remove the code in the case of collections that do not need this HTML, and to provide the appropriate url for the browse feature for collections that do have browse features.

ProcIns Module

The ProcIns.pm module is an object-oriented DLXS middleware Perl module that handles the processing of PIs found in HTML templates. For more information see ProcIns.pm.