 [UP] The UI language |
The dot notation Variables can be declared with type dialog, and because of this it is possible that a dialog stores a subdialog in a variable. The question arises how you can access subdialogs like in:
<ui:dialog name="calling_dialog" start-page="...">
...
<ui:variable name="v" .../>
...
<ui:page name="calling_page">
...
As in many other dialogs, you can now go to our
<ui:a name="call_event">special dialog</ui:a>.
...
</ui:page>
</ui:dialog>
<ui:dialog name="called_dialog" start-page="called_page">
...
<ui:variable name="caller" type="dialog"/>
...
<ui:page name="called_page">
...
You can now do ... this ... and ... that.
<ui:a name="return_event">Return to previous dialog.</ui:a>
...
</ui:page>
</ui:dialog>
(See the section about Data types, it discusses
the same example from another view.) Of course, when the calling
dialog instantiates the called dialog, it stores itself into the
dialog variable caller, so the previous dialog is preserved,
and can be reactivated when the user wants to return. The variable
caller is not only an abstract container for the original
dialog, because it is possible to access the contents of the calling
dialog from the called dialog by using the dot notation.
For example, the variable v is available under the name
caller.v, i.e. the name is prefixed by the name of the variable
storing the dialog, separated by a dot. You can use the dot notation
everywhere a variable is referenced, e.g.
<ui:dynamic variable="caller.v"/>or just ${caller.v}
It is even possible to access variables from O'Caml (or Perl) by
the dot notation:
let v = dlg # string_variable "caller.v" in ...Note that a dialog variable is either empty (or None in O'Caml), or filled (Some dlg in O'Caml). Because of this, the "dot" access can cause an error condition when the dialog variable is empty. |
