From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA18621; Sun, 23 Mar 2003 21:52:18 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA19112 for ; Sun, 23 Mar 2003 21:52:17 +0100 (MET) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h2NKqGf21431 for ; Sun, 23 Mar 2003 21:52:16 +0100 (MET) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18xCS0-0006qb-00; Sun, 23 Mar 2003 21:52:16 +0100 Received: from [80.129.101.32] (helo=gate.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18xCRz-0000Yz-00; Sun, 23 Mar 2003 21:52:15 +0100 Received: from ice.gerd-stolpmann.de (ice.gerd-stolpmann.de [192.168.0.13]) by gate.gerd-stolpmann.de (Postfix) with ESMTP id B9E675717; Sun, 23 Mar 2003 21:53:35 +0100 (CET) Received: by ice.gerd-stolpmann.de (Postfix, from userid 1000) id 92F7BB030; Sun, 23 Mar 2003 21:52:24 +0100 (CET) Subject: [Caml-list] WDialog-2.00 released From: Gerd Stolpmann To: caml-list@inria.fr, wdialog-users@sourceforge.net Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1048452743.11791.98.camel@ice.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Mar 2003 21:52:24 +0100 X-Spam: no; 0.00; gerd:01 stolpmann:01 wdialog-:01 2.00,:01 toolkit:01 apis:01 wdialog:01 hosted:99 sourceforge:01 runtime:01 dialogs:01 persistency:01 behave:01 gui:01 widgets:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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. One can include all HTML tags in pages, but also special elements generating special contents, and controlling the generation process 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 . 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