WDialog

Document Tree

NAVIGATION

Caml Components

Findlib

Ocamlnet

XML

WDialog

RELATED

The WDialog homepage

Contact

WDialog is an environment to create web applications. It is a good choice for "dialog-intensive" applications with many input and output fields, and for application that need exact control of the possible user interactions.

As WDialog is a large project, it is hosted at Sourceforge. The homepage, the download files, and the complete CVS repository can be found there.

In contrast to the other O'Caml components, WDialog is licensed under the GPL.

Separation of the user interface (UI) definition from the backend program, improving the structure of the application and enabling advanced software engineering processes
The UI definition is contained in an XML file, and it describes the whole UI from the overall dialog structure to the style of the individual HTML element
The dialogs have built-in persistency for session state. The HTML form elements can be tied to dialog variables reflecting their current state
A powerful template system manages the combination of individual HTML fragments to whole page
The dialogs behave like GUI widgets. They visualize the state of the session, and user clicks are treated like events that are handled by programmable callback methods
The callbacks are written in a real programming language (Objective Caml, or Perl), making it possible to formulate all algorithms and to use all system resources
The application can run as CGI as well as application server
The WDialog toolkit itself does not require any database as backend store
The UI definition is contained in an XML file, and it describes the whole UI from the overall dialog structure to the style of the individual HTML element
The dialogs have built-in persistency for session state. The HTML form elements can be tied to dialog variables reflecting their current state
A powerful template system manages the combination of individual HTML fragments to whole pages
The dialogs behave like GUI widgets. They visualize the state of the session, and user clicks are treated like events that are handled by programmable callback methods
The callbacks are written in a real programming language (Objective Caml, or Perl), making it possible to formulate all algorithms and to use all system resources
The application can run as CGI as well as application server
The WDialog toolkit itself does not require any database as backend store
WDialog preprocesses all web inputs, and ensures that minimum security standards are fulfilled

The application is considered as a number of dialogs, i.e. groups of interactions that share the same state. Dialogs are defined by terms of object-oriented programming. There is a class-like definition for the user interface containing which dialog variables exist, and which output methods ("pages") can produce visualizations of the dialog state. This definition focuses on the user interface as such, and because of this it is also known as the "user interface definition". This definition is given as an XML file, e.g.

<ui:dialog name="foo" start-page="start">
  <ui:variable name="x" type="string"/>

  <ui:page name="start">
    <html>
      <body>
        One can include all HTML tags in pages, but also special
        elements generating special contents, and controlling the 
        generation process
        <ui:text variable="x"/>
        <ui:button name="q" label="Trigger event 'q'"/>
      </body>
    </html>
  </ui:page>
</ui:dialog>

Within the output methods (inside ui:page), one can use normal HTML elements intermixed with the special user interface tags that have the "ui:" prefix.

Of course, it would not be realistic to write the whole application in a language that is restricted by the XML syntax. This works well for the I/O part of the application, but not for the algorithmic part, and not for the database part. Because of this, there is also a backend program that is written in a universal programming language. Usually, there is a class for every dialog, and the class defines certain methods that are called in certain phases of the overall request processing. In particular, one can program "pre actions" that are executed just before a page is generated, and "post actions" to handle events resulting from mouse clicks. There is a registry saying which class is used for which dialog.

Dialog state is made persistant between page invocations. This is done by data marshalling; one can either include the marshalled dialog literally into the HTML page, or a reference to a backend store. The effect is that the dialog variables ("x" in the above example) keep their value automatically, it is not necessary to pass them explicitly from page to page.

There are special variants of the HTML form interactors like <input>. These variants are bound to dialog variables, i.e. they are initialized from the current variable state, and user modifications are propagated back to the variables. For buttons and hyperlinks, there are variants of the standard HTML elements that "send events". WDialog automatically recognized when such buttons and links are clicked, and the "event" is extracted from the request, and stored as a regular O'Caml value. Usually, these events are evaluated by user-written in code in the post action method.

This is just a small introduction into the basic concepts, so I do not go further here. The reference manual contains some introductory chapters, and there are smaller and bigger examples of code that hopefully explain arising questions. You can find links to the manual and to examles on the homepage.

This web site is published by Informatikbüro Gerd Stolpmann

Plasma	GitLab	Archive
Projects	Blog	Knowledge