| WDialog |
You can make web applications, i.e. applications with a web frontend. These look like normal web pages, but pressing buttons and hyperlinks invokes your code instead of returning only static pages. The applications can become quite complex, comparable to applications on your desktop.
Wdialog is dialog-centric , not page-centric. Not only the problem of generating HTML from page fragments is addressed, but the whole dialog cycle. For example, an HTML button is not only a button, but also part of the current dialog, and it is considered as an operation of the dialog that can be triggered by the user (when he presses the button). WDialog knows that there is a button, and it preprocesses the "button" event before it forwards the event to your callback code. And your code can access the state of the dialog the button is member of. Effectively, programming for WDialog is more like programming a GUI than a conventional web application.
The preferred language is Objective Caml, a dialect of ML. WDialog itself is written in O'Caml, and you have access to all features of the system. O'Caml was chosen because (a) I like it, (b) There is no hype around it, (c) It is a typed language with one of the richest type systems, (d) It is optimal for the combination of symbolical and string-based processing that is needed for web applications, (e) It has quite good run-time performance (better than Java).
If this is too much innovation at once, there is also a Perl API[1], so you can write the application in Perl. However, there are some disadvantages. First, the Perl API does not provide all features of WDialog, for example, you do not have access to the session manager. The Perl API is considered as secondary interface that is extended by need. Another disadvantage is that the WDialog code is executed only by the O'Caml bytecode interpreter, and runs with reduced speed (but still very acceptable). We have currently two productive applications that are written in Perl, and these are our main motivation to provide the Perl API.
WDialog has a user interface definition language (or UI language for short). In this language, the whole input/output behaviour can be expressed. There are usually two kinds of phrases: Some parts of the language are interpreted by WDialog, and some parts are taken as the generated output. The UI definitions are XML documents, and the namespace concept of XML makes it simple to distinguish between the two parts. Elements beginning with "ui:" (e.g. <ui:form>) are WDialog instructions, and the other elements (without namespace prefix) are taken as XHTML.
But the really interesting fact is that the HTML code is completely separated from the application program. It is possible to develop the HTML visualization and the application logic independently.
WDialog as such does not need databases, and it does not specify any way to access databases. Of course, every serious application needs databases, but this is simply not what WDialog is about. You have to program the database accesses yourself.
By default, it does not need databases for that. WDialog has a facility that we call "instant session manager", and it is like instant soups: Just pour hot water on it. The idea of the instant session manager is to keep the whole session state in hidden form fields, so it is not necessary to have an external store for the state. The state is normally less than 50k, and so it is not a big problem in LANs to transfer these data with every request from the client to the server, and back.
Of course, there are situations where it is not tolerable to transfer these data, or to allow that users can read the state. The session manager can be replaced by a different one. There is an example that demonstrates how to store the session in a GDBM database.
No, WDialog does not use cookies.
Basically, it is not necessary that Javascript is activated in the browser. However, there are some features that only work when Javascript is enabled (roughly, the <ui:a> links need Javascript, and popup windows).
Basically, any browser is supported. The core of WDialog uses only HTML-2.0 features, but it of course not limited to that.
That depends on the way the web server and the WDialog application are connected. If this is CGI, any web server should do, but the performance is limited[2]. Alternatively, the JServ protocol is supported, too. In this case, the WDialog application runs as daemon, and the web server connects to this daemon. This requires that the web server has a special plugin that is only available for Apache (mod_jserv - I don't know whether mod_jk also works, it would be available for more servers).
Applications written in Perl must use the CGI interface. It might be possible to load WDialog into mod_perl, but I have not worked on this feature for months.
Basically, a Unix-style operating system is required - sorry, no Windows. Certain features depend on the processor, and on the operating system. The O'Caml bytecode interpreter should work with every processor and with every OS. However, the native-code compiler is only available for certain processors and for certain OS (but it is a wide range of current platforms).
The Perl API needs the dynamic loading feature that was recently introduced into O'Caml. It is only available for some systems (the docs mention Linux, FreeBSD, Tru64, Solaris and Irix). Furthermore, gcc is required to compile the Perl API.
WDialog is distributed under the General Public License (GPL) of the Free Software Foundation.
This depends on (a) whether you distribute the application, and (b) on your business model. In general, if you distribute your application (i.e. give it to another person), the conditions of the GPL must be fulfilled, and this means that your application is also under the GPL, with all consequences (it becomes freely redistributable, etc.). Whether this is acceptable for you, depends on your business model. For example, you can make the application freely available on your web site, and sell only consulting around it.
It is perfectly legal to use WDialog for in-house-only applications that are not distributed. In this case, the conditions of the GPL are not applicable.
No.
In general, this is not supported. The whole application must happen in a single frame. However, it is possible to "route" events from another frame to the application frame by writing explicit Javascript code.
Yes. For example, if you declare a WDialog variable
<ui:variable name="sample"/>you can set this variable to an arbitrary value by passing the CGI parameter var_sample.
You can turn this off (for security reasons) by declaring the variable with protected="yes":
<ui:variable name="sample" protected="yes"/>
There are currently two debugging aids. First, you can put the processing instruction <?wd-debug?> into the ui:application element (directly after the <ui:application> start tag). This causes that the generated HTML pages contain HTML comments with a lot of debugging info, including the current values of variables.
Second, you can write to stderr (Apache only), and find your messages in the error log file.
Better debugging techniques are in preparation.
| WDialog |