|
Data Injection Markup Language
|
|
ESSI |
<%%A_VARIABLE%%> |
|
Php |
<? echo "$VARIABLE"; ?> |
|
Microsoft XTH |
<%VARIABLE%> |
|
CGI Perl |
print STDOUT "$VARIABLE"; |
|
CGI C |
printf("%matching_format", VARIABLE); |
4.2.1.3 Nesting implicit string conversions
The string resulting of an implicit conversion may in turn be considered as potentially containing DIML statements. The example below shows such a situation, after a template call has been substituted :
<% text of some template .. <%%VARIABLE%%> .. end of the template %>
In that particular situation, the outer expression is evaluated first (the surrounding template), and substituted as required. The resulting expression is than parsed again (for inner DIML statements) to calculate the final value for the statement.
The parsing continues until there is no more substitution to proceed, either because there are not more ESSI statements in the string.
ANYWAY, ESSI STATEMENTS RECURSION SHOULD ALWAYS BE PERFORMED WHILE ANY DIML STATEMENT APPEARS TO BE INDENTIFIABLE IN THE SUBSTITUTED RESULT. EXPLICIT NESTED CALLS ARE ALLOWED PROVIDED THE INNER CALL IS SGML ESCAPED.
As a consequence, the following declaration :
<% ESSI statement .. <% ESSI statement %> .. end of statement %>
is not allowed, but should be replaced by :
<% ESSI statement .. <% ESSI statement %> .. end of statement %>
4.2.2 Arrays
4.2.2.1 Use of arrays in ESSI substitutions
Main goal of the ESSI extension is to provide a mean to completely separate the design of the pages from the logical part of a development. This is barely possible when the documents results from iterative writings, say, after requesting in a data base.
Generally the code for requesting, reading and processing data fields in a record needs the two part of the code to be closely mixed.
The array solution of the ESSI syntax is a walkthrough to this issue.
4.2.2.2 The Array [] operator
When a variable is called using the array operator [] (example : %VARIABLE[]%) the variable is assumed being an iterative access to an array.
The array values are accessed in the same order the variable calls are evaluated. An index iteration is proceeded at the end of each template evaluation. Thus, in the same template, a array call keeps the same value. The example :
<TEMPLATE id="testTemplate"> <TR><TD><%%ARRAY[]%%></TD><TD><%%ARRAY[]%%></TD>><TD><%%ARRAY[]%%> </TD></TR> </TEMPLATE>
constructs a table row containing the three same values %ARRAY[]% at the array current index.
4.2.2.3 Relative data access in arrays
Sometimes it may be interesting to access an array somewhere else than where is pointing the current index. The ESSI syntax allows to access an array specifying a relative offset from the actual index.
The relative offset can be either a forward or backward seek, and is expressed as a position counter.
%ARRAY[-1]%
accesses to the past value in the ARRAY array. %ARRAY[+2]% accesses to the second next value in the ARRAY array. Any "out of bounds" call results in the %NULL% variable.
4.2.2.4 Array value and scalar value of a variable
A variable name may be used simultaneously as a scalar and an array access. When this happens, the scalar value and array value are distinct and may not be confused.
%variable%
adds one extra value to the content of
%variable[]%
4.2.2.5 Reading current indexes of arrays
An array should store permanently its current index (within the scope of the process of one single document) to be able to retrieve subsequent values when it is injected again later in the template. A convenient way to keep trace of this index is to store it a scalar variable name related to the array.
To avoid confusion and preserve simplicity, we strongly recommend that any index be stored in variables which name is constructed on the array name basis, postpending a .
%ARRAY[]% should be driven by %ARRAY% index variable
4.2.2.6 Use of arrays in the "main body"
Originally, arrays were associated to an iterative construction using ESSI templates. What happens if an array call is performed in the main body of an DIML source file ?
The simplest way to react is to access the array variable at the current index value that was left after the last template iteration. According to the rule that indexes iterates only after a template substitution, no iteration take place when the array is accessed inside the "main body" part of the document.
4.2.2.7 Multidimensional arrays
In case of nested template calls, a variable entry might be used for scanning a multidimensional data structure. An example of this is when using a single variable name, say %CELL% to construct a table of technical data. In that particular case, it could be convenient to accept a multidimensional form to a variable as
%CELL[][]%
With such a form, it should be possible to write a template for a table cell as :
<TEMPLATE ID=a_single_cell> <TD><FONT COLOR="#000080><%%CELL[][]%%></FONT></TD> </TEMPLATE>
which should be called by a "row" template such as :
<TEMPLATE ID=a_single_row> <TR> <%template file=#line_label> <%template file=#a_single_cell iterate=3> </TR> </TEMPLATE>
where "line_label" should be a template giving the row labels in the table :
<TEMPLATE ID=#line_label> <TD><%%LINE_LABEL[]%%></TD> </TEMPLATE>
Telling how the iteration works may be a bit complicated, and will induce implementation, but is an absolutely necessary definition to explore the most powerful syntactic expressions of the ESSI specification.
When an array variable is evaluated, the Processor starts calculating the rightmost index, based on the effective value of the "array current index" stored in an additional scalar variable associated with this array. This index is the simplest to calculate, but should be reset to 0 IF THERE ARE any upper index level (to scan a new line of an array when the surrounding template call iterates). This is a major change relative to the initial definition of the iteration rules. Conversely, if this index level is the outermost (leftmost bracket pair), the index value should not be reset to 0 to allow subsequent calls to template to keep on iterating from the last reached position (I told you it was somewhat complicated !!).
4.2.3 Calibrating substituted strings
The ESSI procedure allows accessing data without any presentational attributes. Thus, any layout and rendering attributes should be defined in the HTML code in the template files. Isolating design and data processing considerations can result in faulty renderings if the result string is longer than the maximum graphical length allowed for this information. This is a frequent cause of trouble in text processing applications using auto line wrap around features, or in Web auto-calibrating layout.
As a default, the data substitution is not calibrated (ie, the string obtained when data value is converted has no size limit, and will be substituted entirely).
It should be possible to control from the template some parameters of the string being inserted. This will result in additional attributes in a data injection statement. Some of these parameters are also used in template call statements.
4.2.3.1 Where should be written the calibrating attributes
The calibrating attributes are modifiers that have direct influence on the way an expression is converted to it's string representation. Thus, it is assumed that the formatting attributes could be mentioned wherever it is useful.
The first use of formatting modifiers occurs in the single variable conversion :
%A_Variable MAXLENGTH=10 FORMAT=###.##%
However, the format modifiers should be also used in the final ESSI expression (as there is conceptually a last implicit string conversion of the final value of the statement. So the following is acceptable:
<%if (test) %variable FORMAT=#*.###E% else %alternate FORMAT=0*H% MAXLENGTH=6 %>
The MAXLENGTH attribute will be than distributed in both alternatives of the <%if ... %> statement.
4.2.3.2 The MAXLENGTH attribute
The MAXLENGTH attribute defines the maximum char length of the string that will be substituted to the injection statement. The MAXLENGTH's argument is a char count expressed as an integer. If the result of the substitution process is a string which length exceeds the MAXLENGTH specification, then the string will be chopped to match the required length.
This attribute may be used by a designer to protect a layout from inconsistent data. It may be difficult to exactly set this attribute, as many fonts do not use a single character width.
4.2.3.3 The MINLENGTH attribute
The MINLENGTH attribute defines the minimum char length of the string that will be substituted to the injection statement. The MINLENGTH's argument is a char count expressed as an integer.
The primary behavior for this parameter is to force adding non breaking spaces to the resulting string if its length is lower to the specified value. The substituted string will than have at least MINLENGTH characters, that could be translated as a pixel size when used on a fixed width font.
4.2.3.4 The DEFAULT attribute
The DEFAULT attribute allows the user to define an alternate string to be substituted if the variable returns nothing (a blank string).
4.2.3.5 The NULL attribute
The NULL attribute allows the user to define an alternate string to be substituted if the variable returns %NULL% (standing for an undefined or missing variable in the input array).
4.2.3.6 The FORMAT attribute
The FORMAT attribute is defined to allow users to deal with numerical variables. The final action of the ESSI processor is always to print a string evaluation of the data being inserted. This attribute only adds some control on the way the conversion is performed.
Its value is a mask that indicates how the value in the variable should be printed. The mask should be quoted as there can be some literal spaces in it.
The usual symbols that should be used in a print mask are :
# - do not prints non significant zeros.
0 - forces a zero to be printed at that position if it were not
significant at that position, either the number.
. - indicates the position for the decimal point
. - indicates the position for the decimal period (latin representation)
e - when inserted at the end of the mask, indicates that the number
should be written in a scientific format, with a one significant
digit mantissa, and a conventional signed exponent part.
E - when inserted at the end of the mask, and followed by an
integer number, means that the variable should be printed in a scientific format with fixed exponent value. The exponent width is the number that follows the 'E' symbol.
H - when inserted at the end of the mask, stands for an hexadecimal representation.
* - only in use after a 0 or # mark as a "any number of" modifier
The format defaults to the standard string conversion of the "print" or "echo" primitive of the implementation language for the ESSI processor.
The default format will give the conversion below depending on the nature of the variable :
the variable is an integer : #*
the variable is a floating point number : #.#*E#*
4.2.4 Predefined variable names
Some special variable names are predefined, and are used to pass a signal to the ESSI parser. In case a predefined variable is detected, it will be not be directly substituted. A special processing will be made, resulting sometimes in no substitution at all.
4.2.4.1 The %NULL% signal
A processor can temporarily use a %NULL% signal to indicate that an expected hash entry cannot be found. The parser will substitute an alternate string if it is defined by the NULL attribute of a variable call. The default string value to be substituted is "" (the blank string).
You should notice that the %NULL% signal is equivalent to a %NULL% entry in the input hash that defaults to "".
The %NULL% special variable will evaluate in order :
a NULL attribute in the variable call
a NULL entry in the input hash array
the empty string
4.2.4.2 The %ERROR% variable
A parsing operation may result in an error situation especially when the FORMAT attribute is defined, and the representation cannot be converted. Sometimes the error may even occur when the script tries to compute the variable. The content of the %ERROR% should at least match the following pattern.
error_code : error message
4.2.4.3 The %CGI::...% variables
The %CGI::...% variable calls group centralizes direct calls to CGI standard interface variables such as REMOTE_HOST, USER_AGENT, QUERY_STRING etc, allowing a designer to include some of these information in the document, or a software developer to perform some test from the remote end.
4.2.4.4 The %ENV::...% environement variables
The %ENV::...% set of variables allows a direct binding to the other environment variables. This will give designers direct access to these variables to compose the final document, and will allow smart debugging in complex procedures.
4.2.4.4 The %FORM::...% form entries
The %FORM::...% set of variables allows a direct binding to form entries, when the document is issued from a CGI complying request. This will give designers direct access to these variables to compose the final document, and will allow smart debugging in complex procedures.
4.2.5 Defining variables from DIML side
4.2.5.1 What for ?
Defining variables is a necessary feature to allow hiding some constructs to the designer. As an example, consider a CGI function call that needs to be activated through a Javascript function in order to hide explicit printing of the request string in the client widgets.
The typical case above could be written like this :
<HEAD>
<SCRIPT LANGUAGE=Javascript>
function FormLaunch(formname, actioncode)
{
document.form[formname].action.value = actioncode;
document.form[formname].submit();
}
</SCRIPT>
</HEAD>
...
<FORM NAME="CgiCall" ACTION="/cgi-bin/cgiCall.exe" METHOD=POST>
... form items ...
<INPUT TYPE=hidden NAME=action VALUE="defaultActionCode">
<A HREF="Javascript:FormLaunch('CgiCall', 'anAction')">
<IMG SRC="some_image.gif" BORDER=0>
</A>
</FORM>
The challenge is that the most part of the technical implementation could be hidden whithout reducing flexibility in how the form elements are placed and shaped. The variable definition feature, along with the "header element recollection" capability, will allow such an improvement.
The following shows how to reduce the form submission code :
<A HREF="Javascript:FormLaunch('CgiCall', 'anAction')">
<IMG SRC="some_image.gif" BORDER=0></A>
to the single expression :
<% %anAction()% %>
while the designer still will be able to choose which image is used to represent the activator :
<IMG SRC="some_image.gif" BORDER=0>
4.2.5.2 Defining variables as templates, the INLINE attribute
First soluce will construct a developper side template as :
<TEMPLATE ID="anAction()">
<A HREF="Javascript:FormLaunch('CgiCall', 'anAction')">
<IMG SRC="<% %IMAGES_ROOT_UTL% %><% %anAction_image% %>" BORDER=0></A>
</TEMPLATE>
then allowing a designer side template to define the source of the image :
<TEMPLATE ID="anAction_image" INLINE>
a_path/an_image.gif
</TEMPLATE>
The INLINE attribute specifies here that the leading and trailing newline are not part of the template content (and so the association <% %IMAGES_ROOT_UTL% %><% %anAction_image% %> will not roll off at the end of the image root path string. The INLINE template above starts with an 'a' as first char, and ends with an 'f'.
4.2.5.3 The SET statement
The SET statement allow the designer to pass explicitely some variables to the script author's side. The author should use these variables to produce some hidden constructs. The syntax for a variable definition statement is :
<%set %VARIABLE%="quoted_string" %>
Double quote may be omited if the quoted_string contains no white spaces.
Variables are defined from the point the SET statement is parsed. The value is available from this point using a single call syntax :
<% %VARIABLE% %>
The variable definition feature may be used to "reset" some iterative table pointers (ie. reseting the first cursor of the table_name[] table known as table_name when using the Perl ESSI Processor).
The above example should be written :
... <FORM <% %CGI_CALL% %> > ... form items ... <%set %CGI_CALL->IMAGE% = "http://some.host/some/path/some.file" > <% %CGI_CALL->ANACTION()% %> </FORM>
The script author will define :
a template internally (in the script source, or as an external template in a separate file) :<TEMPLATE ID="ACTIVATOR_CGI_CALL" > <HEAD> <SCRIPT LANGUAGE=Javascript> function FormLaunch(formname, actioncode) { document.form[formname].action.value = actioncode; document.form[formname].submit(); } </SCRIPT> </HEAD> <INPUT TYPE=hidden NAME=action VALUE="defaultActionCode"> <A HREF="Javascript:FormLaunch('CgiCall')"> <IMG SRC="<ANACTION_IMAGE% %>" BORDER=0></A> </TEMPLATE ID="ACTIVATOR_CGI_CALL" >The name (ie CGI_CALL and CGI_CALL->ANACTION()) of the DIML calls involved in the action. Note here that we choosed an "object oriented" notation that will depend on capability of the DIML Processor. This is a "a posteriori" rationale to the encapsulation of variable names between two '%' characters, as it allows larger variable name conventions to be used.
The name (ie CGI_CALL->IMAGE) of optional variables the author will need to construct the hidden template.
Note : please note that the SET statement could be written at any place in the DIML source document
4.3 Structural markups
4.3.1 Templates
Template is a way to optimize Web document encoding, extending the entity concept to sub-entities. The underlying idea is that any Web page (or any page in a document) layout has sub-components that can be semantically isolated. For example, a typical catalog index should have some general header indicating who is the owner of the catalog, then will follow a high level menu for global navigation in the whole Web site. Then will follow a toolbar which makes the catalog manipulation easy. Then comes the actual list of selected or sorted items.
HTML has a major limitation till now. As application of an SGML document, a document contains generally a single HEAD section, and a BODY section. The unique alternative to this would be a FRAMESET definitions that parts the layout into independent frames, each one loading a new document file.
It has been largely proved that frame structures are a bit tricky to manipulate, especially in dynamic systems. The main interest in FRAMESET is the relative gain in network bandwidth as frames still consistent will not be loaded again when something on the screen must change (see the TARGET attribute of the A element in HTML 3.0).
A template gives a new approach for the improvement of document's structures and reusability of HTML code.
4.3.1.1 Template definition
An ESSI template is defined as a fragment of HTML document in which some ESSI variables can be injected. Any HTML construct can be written in a template. Eventually, a template could include a whole HTML page. This is the way it is implicitly understood in DIML documents.
An ESSI template is defined as an SGML element that adds its definition to the HTML standard element list.
An ESSI template declaration starts with a
<TEMPLATE>
start tag and ends with a
</TEMPLATE>
end tag (as commonly used in HTML definitions)
A template definition should normally occur only outside a standard BODY element. But, as ESSI statements are processed before sending the document, it won't cause any trouble to insert a template definition in a BODY, or HEAD section. The ESSI processor should not leave any template definitions in the processed document.
Don't be astound that our constructs are close to standard SGML declarations. We must assume that one day, ESSI statements could be used at user agents side (who knows ...!).
4.3.1.2 Attributes
A template has a basic ID attribute which assigns a name to the template. This name is mandatory if the template has to be recalled by a substitution statement. The ID may be any quoted string as defined in the SGML definition, or a single token unquoted if no separator is used in.
The INLINE attribute : see defining variables as templates
4.3.1.3 Template element contents
A template may contain a fragment of an HTML document, but can also contain a HEAD element. This HEAD element should be concatenated to the actual HEAD element of the main HTML fragment, when the substitution statement is executed. The content of the HEAD section should be inserted only once in the main HEAD section, even if the template is used twice or more times. For example, the DIML code :
<HTML>
<HEAD> some main header code...</HEAD>
<BODY>
<% template file="#one" %>
<% template file="#one" %>
</BODY></HTML>
<TEMPLATE ID=one>
<HEAD>
<SCRIPT TYPE=Javascript>
function TemplateSpecificFunction()
{...}
</SCRIPT>
</HEAD>
some HTML body code...
</TEMPLATE>
should produce, once processed :
<HTML>
<HEAD> some main header code...
<SCRIPT TYPE=Javascript>
function TemplateSpecificFunction()
{...}
</SCRIPT>
</HEAD>
<BODY>
some HTML body code...
the same HTML body code...
</BODY></HTML>
There is today no provision for cumulating some indexed HEAD items.
The content of a template can include itself other variable substitution calls, or other template calls, which should be processed before inserting the content into the calling fragment.
4.3.2 Template calls
4.3.2.1 Single call
An ESSI template can be recalled whenever in a DIML fragment, even prior its effective definition. This implies templates MUST be cropped before the substitution operations start.
A simple call is proceeded by a calling statement in the DIML source file :
... HEAD statements
<BODY>
<H1>titre</H1>
<P><%template src=a_valid_fragment_URI %>
The file attribute pointing on the desired template may be used as a standard fragment URL, pointing on an HTML fragment. The template's id is to be considered as a fragment anchor. Thus, a template might be fetched in another DIML source file. Here come some examples of some classic situations :
The following statement :
<%template file="#template_id" %>
calls a template defined somewhere in the same source file. The statement :
<%template file="some_relative_path/some_document.diml#template_id" %>
will search for a template named "template_id" into a file designated relatively to the current path.
In order to cope with SSI inclusion restrictions the file attribute should not accept any ".." in it.
To point into a file located somewhere else in the file system, you should use the virtual attribute, so :
<%template virtual "../a_file.diml#a_template" %>
is valid.
The file or virtual attribute should always be local pathes. Trying to include files outside the local host space, say, trying to use an http: prefix, is not allowed yet (that is, no protocol nor machine name should be mentioned).
4.3.2.2 Array call
Templates are also made to provide a painless mean to define HTML layout models that should be applied as an iterator in an HTML document dynamic construction process.
A Web page resulting from automatic database extraction, or any other programmatic construction shows often repetitive elements. This repetition is the consequence of the iterative way the page has been constructed.
Thus, the ESSI syntax proposes a way to use a template as iteration model.
For example, lets consider an answer of a search engine to a query for some topic. Usually, the search results are obtained from a database, and a Web page is constructed with such results, giving something like :
<BODY>
<H1>Results from your query :</H1>
<TABLE>
<TR WIDTH=400>
<TD ALIGN=top WIDTH=40>1 -</TD>
<TD ALIGN=top WIDTH=400>
<A HREF SRC="http://a.server.com/a/resulting/url.html">
http://a.server.com/a/resulting/url.html</A><BR><P>
<FONT COLOR="#FFFF80" SIZE=-1>Some information associated
with this link</FONT>
</TD>
</TR>
</TABLE></BODY></HTML>
Suppose now that your query is answered by 10 matching url. The <TR>...</TR> line should appear 10 times, with a sequence number in the left cell, and each link written close to its description in the right cell.
This could be the result of an array call of an ESSI template using array variables :
<TEMPLATE ID="aSingleRow"> <TR WIDTH=400> <TD ALIGN=top WIDTH=40><%%SEQUENCE[]%%> -</TD> <TD ALIGN=top WIDTH=400> <A HREF SRC="<%%MATCHING_URL[]%%>"><%%MATCHING_URL[]%%></A> <BR><P><FONT COLOR="#FFFF80" SIZE=-1><%%MATCHING_INFO[]%%></FONT> </TD> </TR> </TEMPLATE>
An array call is just like a single call, excepted that its syntax denotes an array usage of the array variables that are used in :
<%template file="#a_template_anchor" iterate=10 %>
means that a maximum of 10 rows can be printed in the resulting HTML code, even if more than 10 records were extracted from the database. The way the script should manage paged layout depends on the script itself, and of use of special variables as counters. To force consistency of the model, a single call should be thought as a single iteration array call of a template, so :
<%template file=#a_template %>
and
<%template file=#a_template iterate=1 %>
are equivalent.
This call causes the ESSI processor to iterate the input hash structure, incrementing related indexes depending on the inclusion nesting level and the table dimension.
4.3.2.3 Overriding repetition count limitation
In some applications, the result page must flow continuously down, rendering the whole resutl list of a single request. The following syntax allows overriding the previously defined limitation and proposes a "while there are data" form of the iterated template call.
<%template file="#a_template_anchor" iterate="*" %>
4.3.2.4 Rules for reusing templates or variables
As it has been foreseen, array indexes are iterated as soon as the surrounding template has been evaluated. This has two major consequence :
- No iteration can take place in the global fragment of an DIML file.
- When a template is later recalled, iteration continues where it stopped after the first iteration loop.
- As all indexes always restarts to 1 when a document is parsed, a designer should not rely on sequence continuity between two Web pages.
4.3.2.5 Nested iterations
As nested template calls are allowed, it may be useful to describe how should behave a fully featured processor when nesting array calls to some templates. Here comes an example of such a situation :
<TEMPLATE ID="inner_loop"> <%%SOME_ARRAY[][]%%> </TEMPLATE> <TEMPLATE ID="outer_loop"> <%template file="#inner_loop" iterate=3 %> </TEMPLATE> Some part of main body... <%template file="#outer_loop" iterate=5 %>
The expected result of such a construct is a square array of 5 x 3 cells, in which each value should correspond to the input array segment [SOME_ARRAY, SOME_ARRAY].
The global scheme of array management is discussed in a complementary document
4.3.2.6 Simplified access to local templates
Resulting from a clever comment of one of my students, who found somewhat ugly the calling syntax, especially when the DIML file was monolithic, a simplified alternate access syntax has been added to the initial <%template ... %> call.
Experimenting the processor, we noted that adding the template content as a new entry of the input hash array could be convenient. A local template can thus be directly called as a local ESSI variable, where the variable name is the unique ID in the template declaration.
The direct call syntax will be extended to a local array call, adding brackets to the ID key.
As an example, if a local template is defined as follows :
<TEMPLATE ID="a_template"> Some DIML text ... </TEMPLATE>
then a template substitution in a body section could be notified by the simple call :
<% %a_template% %>
If the template contains array access variables, then it would be convenient to call directly the array form :
<% %a_template[10]% %>
or
<% %a_template[*]% %>
Implementation note : Note that variable creation resulting from local template definitions will occur at compile-time (is not implicit in the calling code). The users will take care to avoid naming collisions between in-code variables and template parsing resulting variables.
4.4 Expressions
ESSI statements may use simple control structures. These control structure may willingly remain elementary because the ESSI extension does not pretend to replace scripting languages. It just does provide a way to help structuring complex HTML layouts, and separating the logic and the rendering aspect of a client server mechanism.
4.4.1 Conditional statements
4.4.1.1 The IF...ELSE...ENDIF statement
ESSI statements can be written as a standard conditional structure "if ... else". Complexity of such a structure is not a main goal. They are only defined to improve design of template files and optimizes storing space when different layouts are very similar.
To improve clarification of the DIML source, conditional structures may appear using two distinguishable forms. When the whole statement is written within the same DIML statement, it is called "one shot" statement. When it directly switches between in-line HTML alternatives, it is called "multiline".
4.4.1.2 The "one shot" syntax
The syntax for a conditional statement is :
<%if (condition) expression else expression %>
in which expression may be a single variable or a template call, and condition is an expression that has a final boolean value.
The condition may use any syntax features the native language of the processor will allow, and in most cases, will accept the usual C-condition conventions.
The expression can be a template call, that will produce the insertion of a substituted template where the statement stands :
<%if (%TEST%) %template file="#the_template"% %endif %>
An expression may also be a literal HTML fragment. This form is provided for convenience where the conditional statement is used to switch between two short HTML statements :
<%if (%TEST% == 0) "<HR WIDTH=30>" %else %ALTERNATIVE% %endif %>
The example above shows also that these forms can be combined in any way.
Be carefull to escape correctly the litterals. A litteral quote in an HTML sequence should be marked as the character entity ". The characters :
- ["] double quote
- [<] when followed by a [%]
- [>] when preceded by a [%]
should be escaped to avoid processor confusion.
Notice that the ESSI processor does execute a single pass character entity substitution, based on the character list given in the HTML 4.0 DTD (see the www.w3c.org).
4.4.1.3 The "multiline" syntax
For convenience when large HTML alternatives must be switched, a form similar to SSI conditional syntax is accepted for DIML conditional statements :
<%if (condition) %> some HTML code ... <%elsif (condition) %> a second HTML alternative... <%else %> some other code... <%endif %>
4.4.1.4 Operators in conditions
The ESSI extension recognizes the major comparison operators used in C and PERL :
== equality != difference < lower to (strictly) > higher to (strictly) <= lower or equal >= higher or equal eq equality (lexicographically) lt lower to (lexicographically) gt higher to (lexicographically) ne non equal (lexicographically)
The ESSI extension adds the PERL operators for regexp comparison :
=~ contains scheme !~ does not contain scheme
Moreover, the ESSI syntax allow use of logical operators to combine multiple expression tests :
! unary not && logical AND || logical OR ^ logical XOR
4.4.1.3 The SWITCH...CASE statement
To extend power of conditional constructs, the ESSI definition accepts a switch...case structure to deal with "selector" variables.
The basic form of this statement is :
<%switch (%SELECTOR%) case text_value_expression %> DIML statements... <%case alternative_value_1 %> DIML statements... <%case alternative_value_2 %> DIML statements... <%case alternative_value_3 %> DIML statements... <%case alternative_value_4 %> DIML statements... <%case alternative_value_5 %> DIML statements... <%default %> DIML default code... <%endcase %>
Such a structure works like in ANSI-C, except that no explicit "break;" signal should be written. The "endcase" branch point is automatically reached as the specific "case" has been parsed.
There should have only a few further extensions in statements as ESSI syntax is NOT intended to grow as a programming language. We only thought that developers could spare efforts and time using some minimal conditional features, and thus reducing the number of template files to be written.
5. ESSI document structure
This chapter discusses about possible structure used by DIML documents. Will be detailed the differences between what is induced by the syntactic rules, and the consequences of some extra usage, attempting to specify what should be the reaction of an ESSI processor to such an extrapolated use.
Additionally, this chapter will define some basic rules to indicate how an DIML should be parsed.
5.1 Global section
As an extension of an HTML document, it may assumed that an DIML document could be written using only HTML valid constructs. So any HTML document is an DIML document.
As a consequence, any DIML document may contain a HEAD section, a BODY section, which in turn could contain some inline TEMPLATE defs, and finally some isolated TEMPLATE defs past the </BODY> closing tag.
Will be considered as part of the GLOBAL section any HTML constructs that are defined outside any template definitions. The global section defines the HTML text frame that will effectively be used as the document basis. Conversely, templates must be interpreted as information bricks that are given next to the main body, and that will be used to finalize this body.
A global section may contain any injection scheme or template calls it will need. It globally must be treated as an HTML document would be, once the ESSI replacements are done.
Array calls will be processed as defined in this specification, iterating the index each time the template is fully substituted.
5.2 Template sections
Any code inserted between two section marks is considered outside the global section and may be even never written in the finalized document.
This code can contain injection scheme or other template calls. A special attention must be paid in case of call loops as there is no obligation for a processor to signal this faulty situations.
Template sections MUST NOT be nested - as it would be meaningless - though it is possible to call a template within a template definition.
5.2.1 Use of array calls in a template definition
As template calls are allowed in a template definitions (except recursive calls), it is syntactically possible to call a template using its array form.
In this case, the programmer should beware that ESSI processing of the array will be executed "just-in-time", and the input data arrays will be iterated linearly each time the template is processed.
6. Appendices
Appendix 1 : The ESSI Multidimensional Array Model
Appendix 2 : References
Appendix 3 : Hall of honors
Great thanks to everybody who came to support the project, who listened my elucubrations during all this amount of time, and who gave me the most "psychespace profe award" of the 1999th (wasn't too hard being the unique candidate !).
Special thanks to
- Jean-Louis Campion
Eisti Applied Research LaboratorY (EARLY)
for his constant asistance. - William Godin
EISTI - promo 2002
For his help in testing prototype and concepts - The NTIC students
EISTI - promo 2000
For their criticisms and opinion - Nesim Fintz
EISTI
Our venerated dean - Francis Gibert & Sean Gough
FGP / GS Sensors
Patiently waiting for our results - Edouard Deslandes
Auxicad
For his sympathetic support and encouragements
All material is copyleft V.G. FREMAUX (EISTI France) 1999 to 2003 except explicitly mentioned