EDO

Miscellaneous

Detailing miscellaneous other markups used for such things as flow control, and modular structuring.

• IF
• INCLUDE
• ALTER
• SET

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.

In its simplest form, an <IF> markup follows the following syntax:

<IF CONDITION="condition">
   block of HTML/EDO code, processed if condition is true.
</IF>

The <IF> markup also supports the following simpler syntax (which is technically non-XML compliant):

<IF condition>
   block of HTML/EDO code, processed if condition is true.
</IF>

It can be expanded to also support an <ELSE> block:

<IF condition>
   block of HTML/EDO code, processed if condition is true.
<ELSE>
   block of HTML/EDO code, processed if condition is false.
</IF>

Using the <ELSIF> markup, conditional statements can be cascaded (Note: This is currently not implemented, but is planned for a future revision.):

<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.

For example, if checking if a string field "status" in a record "info" contains the value "ok", the condition would need to be:

<IF '$status.info'='ok'> ... </IF>

The following, although the more logical and neater syntax, will not work:

<IF status.info='ok'> ... </IF>

In addition, always keep in mind the format of the data, and what effect the wrong method may have. If in doubt, specify a method for the field:

<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.

The current supported syntax is:

<INCLUDE VIRTUAL="path/file">

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...

For example; To include a file "/edo/navibar.edo", and pass as the variable "items" (ie; CGI.items internally to the file) the value of field "itemcount" in record "tally":

<INCLUDE VIRTUAL="/edo/navibar.edo?items=$tally.itemcount.esc_http">

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:

RECORD (optional)

This defines which record the field is in to alter. If this is not specified, the default Record is assumed. A record can also be specified in the FIELD parameter.

FIELD (required)

This defines which field is to be altered. If the RECORD parameter is not used, a record can still be specified as part of the Field specifier, using the notation: record.field

TYPE (optional)

This can be used to change the core type of the field.

OTHER (optional)

This can be used to specify a group of properties, using the single-line format as supported by Field Details views.

REFRESH (optional)

This triggers the "refresh" method in the field. This isn't used by most fields, but some which use other dynamic sources to define some of their properties can use this to trigger an update of those properties.

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 a field "ID" in record "People" to be of type "int":

<ALTER FIELD="People.ID" TYPE="int">

Change a select field "options" in record "task" to derive its options from the same source as before, but changing the filter condition to "status='current'", and refresh the options list:

<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:

RECORD

Sets the name of the default record. This is used in most markups which have an optional RECORD parameter, and is also used when a field is referenced without a record. ie; If you're using one record predominantly for a section of code, set it as the default to avoid having to implicitly set it every time.

METHOD

Sets the default method used when referencing fields. Like the default RECORD, setting the default METHOD can reduce the amount of implicit specification when referencing fields. It can also be used in conjunction with <INCLUDE> to provide multi-purpose code. For example, a well-laid out form content, where none of the fields methods are specified, can be included to either Edit or View the contents, by setting the default method to as_form or as_html respectively, before including the form content.

Other planned settings may include: SOURCE, VIEW.