Detailing miscellaneous other markups used for such things as flow control, and modular structuring.
The <IF> markup is used to conditionally control the processing of a block of code. This can be used not only to control whether certain HTML is shown within a page or not, but also can control whether other EDO markups within a block are processed or not.
<IF CONDITION="condition"> block of HTML/EDO code, processed if condition is true. </IF>
<IF condition> block of HTML/EDO code, processed if condition is true. </IF>
<IF condition> block of HTML/EDO code, processed if condition is true. <ELSE> block of HTML/EDO code, processed if condition is false. </IF>
<IF condition1> block of HTML/EDO code, processed if condition1 is true. <ELSIF condition2> block of HTML/EDO code, processed if condition2 is true. <ELSIF condition3> block of HTML/EDO code, processed if condition3 is true. <ELSE> block of HTML/EDO code, processed if all conditions are false. </IF>
The conditions processed in <IF> markups currently follows a syntax which is a mix of Perl and SQL logic. The basic comparators = and != are used to compare two values to see if they are equal, or not equal respectively. Multiple comparisons can be combined using "and" logic (where both conditions must be true for the whole to be true) using either "and" or "&&". Similarly, they can be combined using "or" logic (where either condition must be true for the whole to be true) using either "or" or "||".
As the current and immediate-future planned processing of conditions involves a generic parser, which does not have specific ties to the EDO data structures, it is important to use the '$variable' syntax for referencing variables. Using this technique, it is also important to remember any escaping or quoting for that variable type.
<IF '$status.info'='ok'> ... </IF>
<IF status.info='ok'> ... </IF>
<IF '$status.info.value'='ok'> ... </IF>
Future plans include converting <IF> conditional parsing to using a generic SQL logic processor, either using a separate library, or possibly using any Source with pre-parsed conditions, to allow leverage of SQL advanced functions, as used in the <ASSIGN EVAL=""> markup.
Future plans also include a pre-parser (or other smarts) to support the more logical syntax of record.field.method, to avoid the current kludge that leads to things like '$record.field.method'.
The <INCLUDE> markup allows a block of code to be included from a separate file. It is currently the primary way to create modular EDO code, as separate EDO files can be considered to be separate modules or routines, which can be included as required.
Currently, regardless of file extension, the file is considered to be an EDO file and is parsed as such. The EDO Parser does treat the file as a separate EDO block to parse, and so although all data structures, settings and values are still valid, markup structure is not carried over into the included file. In other words, you can't open a markup in the main file, and close the markup in the included file - it is treated as a separate block of code. Future plans include methods of specifying the file's type, to allow unparsed inclusion, etc...
The path to the file to include can be an absolute URL, or a relative URL. The primary EDO file is always considered to be the base, and its directory is considered the base directory upon which all paths are relative. So, if the primary EDO file includes a sub-file from another directory, and that sub-file then includes another sub-file, it has to reference that sub-file using an absolute path, or a path relative to the primary EDO file.
Although not strictly a traditional structure for subroutine calling, it is possible to pass temporary values through to the included file using the query string syntax similarly used in CGIs. This technique can be handy for creating simple EDO libraries, where an included file expects certain properties, without requiring knowledge of supplied records, sources, etc...
The <ALTER> markup is used to alter the properties associated with a Field in a Record. Fields can be customised in a number of ways; the main method is when a Record is created, and a View is associated with the Fields. This View contains a special structure for describing the properties of fields. The <ALTER> markup is used for small tasks, and where a field's properties need to be altered after a Record's creation. Parameters for it include:
In addition, any general or custom property supported by the field type can also be specified as a parameter.
Here's some examples of Alter statements:
<ALTER FIELD="People.ID" TYPE="int">
<ALTER FIELD="task.options" WHERE="status='current'" REFRESH>
(Note: The ability for select fields to source their info from an EDO view is provided by the optional EDO::Select package, and is not a standard EDO or Fields capability.)
The <SET> markup is used to set certain preferences relating in general to EDO functionality. Currently supported parameters include:
Other planned settings may include: SOURCE, VIEW.