Dot notation (v1.v2)

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.