|Last updated||2003-03-03 16:48:03 EST|
|Doc Title||HTML Templates / Interfaces in DLXS|
|Author 1||Stoeffler, Matt|
|CVS Revision||$Revision: 1.8 $|
The user interface in the DLXS middleware is realized by a combination of interrelated techniques:
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.
There is enhanced template debugging available via the debug=tpl URL parameter. Here's the basic idea of how fallback works:
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.
HTML templates are combined with processing instruction tags that are parsed and replaced by the middleware. Processing instruction tags are of the form
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></TITLE>tags and supplies a collection title string.
Can appear within the
srcattribute 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
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.
<td id="browsetab" width="90" height="23" align="center" nowrap>
<a id="browselink" href="<?COLL_SPECIFIC_CONTENTid="navbarbrowselink"cginame="text-idx">" class="nav" onMouseOver="P7_autoLayers(0)">Browse</a>
<td id="sep3" width="1">
<img src="/t/text/graphics/plug.gif" width="1" height="1" border="0" alt="design graphic">
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.
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.