Docs GODI Archive
Projects Blog Knowledge

Look up function:

(e.g. "List.find" or "keysym")
More options

[UP]
Reference
 Dialogs
 Data types
 Events
 Templates
 Session management and security
 Internationalization
 Output encodings
 Processing instructions
 The UI language
 ui:a
 ui:alist-value and ui:alist-item
 ui:application
 ui:button
 ui:checkbox
 ui:cond
 ui:context
 ui:default
 ui:dialog
 ui:dyn-enum-value and ui:dyn-enum-item
 ui:dynamic
 ui:encode
 ui:enum-value and ui:enum-item
 ui:enumerate
 ui:enumeration and ui:enum
 ui:false
 ui:file
 ui:form
 ui:if
 ui:ifexpr
 ui:iflang
 ui:ifvar
 ui:imagebutton
 ui:iter-*
 ui:iterate
 ui:page
 ui:param
 ui:popup
 ui:radio
 ui:richbutton
 ui:select
 ui:server-popup
 ui:special
 ui:string-value
 ui:template
 ui:text and ui:password
 ui:textarea
 ui:translate
 ui:true
 ui:use
 ui:variable
 t:*, q:*, and p:*
 l:*
 $param
 $[expr]
 Dot notation (v1.v2)
 The standard UI library
 WDialog API (O'Caml)
 Runtime models
   
The UI Language

The UI language is defined in terms of XML-1.0. The subsections explain every element in detail; together they cover the complete DTD of the language.

The hierarchy of the UI elements

The following picture shows the hierarchy. The picture is active, you can click at the elements to go immediately to their descriptions!

The element hierarchy
Picture 5: The element hierarchy
ui:param ui:iter-* ui:iter-* ui:iter-* ui:iter-* ui:context ui:param ui:application ui:dialog ui:enumeration and ui:enum ui:enumeration and ui:enum ui:string-value ui:enum-value and ui:enum-item ui:alist-value and ui:alist-item ui:enum-value and ui:enum-item ui:dyn-enum-value and ui:dyn-enum-item ui:alist-value and ui:alist-item ui:dyn-enum-value and ui:dyn-enum-item ui:page ui:template ui:default ui:use ui:enumerate ui:iterate ui:param ui:server-popup ui:form ui:button ui:imagebutton ui:checkbox ui:radio ui:translate ui:file ui:text and ui:password ui:text and ui:password ui:select ui:textarea ui:a ui:special ui:if ui:cond ui:popup ui:ifvar ui:iflang ui:true ui:false ui:variable ui:dynamic ui:richbutton ui:encode ui:ifexpr
Other syntactic objects

For many reasons, the above ui:name elements are not the best choice for every kind of notation. Because of this, a number of further syntactic objects have been defined:

The semantic levels, and the incompleteness of the formal declarations

The elements shown in picture 5 belong to one of three semantic levels. The topmost element ui:application and its children are the elements that determine the dialog structure, i.e. which dialogs exist, and what are their static properties. The elements inside ui:page are either generative elements, or control structures. The former generate output directly, while the latter control the expansion process (e.g. "if" conditions).

I have tried to give a formal XML declaration for every element. Unfortunately, the XML DTDs are not powerful enough to specify the relations between the elements fully. I found a number of problems, and they are often related to difficulties how to describe the relations between the semantic levels.

Many control structures are declared with a content model of ANY, i.e. the DTD does not restrict the type of the children elements. There are actually two reasons for this. First, the replacement for ANY would be an enumeration of all control structures, and all generative elements. But the latter are not completely known for the scope of the UI language, as all HTML elements are generative, too, and it is intentionally avoided to include HTML as sublanguage into the UI language.

The second reason is that the relations between control structures and generative elements cannot be expressed by the DTD. The control structures are evaluated at expansion time, and change the order of the generative elements dynamically. For example, is it allowed that the TD HTML element is a child of ui:template, a control structure? This depends on where the template is called. If this happens inside TR, the usage of the template will be legal because TD must finally occur inside TR according to the HTML language. However, this condition cannot be expressed in a DTD. You need the power of a type system to check the validity of element relations across semantic levels.

Note that even the attribute declarations are incomplete. Often, the elements of the UI language are only variants of the corresponding fundamental HTML elements. For example, the ui:button element generates an INPUT HTML element with TYPE=SUBMIT. Of course, it is allowed to add HTML attributes such as CLASS or ONCLICK to ui:button as they can be simply copied to the generated INPUT element. In the declarations, these HTML attributes are omitted to avoid dependencies on certain HTML versions.

In the following sections, the semantic level of the element is given in addition to the formal declaration. This helps a lot to find out where (and how) an element can be used: Both control structures and generative elements can only be used in page context, i.e. when the creation of an output page is described. The control structures determine the algorithm how the generative elements are arranged. Finally, the page consists only of generative elements, and these must have a sound structure that is correct with respect to the HTML definition.

This web site is published by Informatikbüro Gerd Stolpmann
Powered by Caml