Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] WDialog-2.00 released
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Gerd Stolpmann <info@g...>
Subject: [Caml-list] WDialog-2.00 released
Hi list,

I have just released WDialog-2.00, the toolkit for dialog-centric web
applications. This release focuses on the maturity of the APIs, and
there is also an updated reference manual. See below for a feature list,
and for a small introduction to get the idea.

WDialog is hosted at Sourceforge, and you find links to all relevant
documents on the homepage: http://wdialog.sourceforge.net

As an improvement of the test releases the reference manual can now be
downloaded as bunch of HTML files, or as a single PDF. (See the download
section of the homepage.) Of course, the online version is still
available. The manual has 242 pages, and describes the toolkit in
detail.

WDialog has already been used to create web applications for our
customers, and there is now even a free application that bases on it:
WTimer. See the link
http://www.ocaml-programming.de/packages/documentation/wtimer.

WDialog is a complicated answer for a complex problem. It is not just
JSP for O'Caml, as it analyzes the problem differently, and comes to
alternate conclusions. It consists of an XML document type, a
programming interface, and a certain way of doing things at runtime;
from this point of view it is an environment for programming web
applications. This means that there is some kind of philosophy behind
it, and you will need some time to become productive with it.

Gerd

************
Feature list
************

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


*****************************
Introduction into the concept
*****************************

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.

-- 
--
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
--

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners