Programmer's Guide to the wftk

[ wftk documentation home ]


The wftk functionality is contained in several libraries which you can call from your own applications. Concrete examples of these applications remain few; the command-line utilities for the wftk core and the repository manager, the Python wrappers, the CGI front-end for the repository manager, and that's about it so far.

It is important to understand the relationship of the various parts of the wftk system before planning and implementing a wftk wrapping application. First and foremost, the XMLAPI exists to handle nearly all data in the system, based on a set of internal data structures corresponding to XML documents. On top of the XMLAPI are the two central modules, the wftk core (which handles workflow-specific actions) and the repository manager (which handles data storage and organization). Since the repmgr itself manages the wftk installation, many if not most applications have no need to call the wftk core API at all. This is the chief reason why I've found time to wrap the repmgr API and the XMLAPI in Python and Tcl and somehow have never gotten around to exposing the wftk core API in those languages.

Data structures

All data structures for the wftk are built as internal XML objects using the XMLAPI. These are the various things you will encounter while working with the wftk: When working in a higher-level language, it's quite tempting to assume that the XMLAPI can be dispensed with. Fortunately or unfortunately, this is not the case. Since the XMLAPI data structures are passed back and forth from the wftk APIs, then you at least need some way of converting your high-level data structures into XMLAPI structures. In many cases, it's simpler just to work with XMLAPI from the start. This isn't to say that the embedded versions of the XMLAPI couldn't work more closely with their languages than they do -- they can. But the internal struct-and-pointer layout of the XMLAPI structures needs to be identical for them to work across language boundaries.

Class schema

The wftk APIs are object-oriented in nature, but are implemented in ANSI C for maximum portability and also because I'm an old curmudgeon who likes to thumb his nose at you young whipper-snappers. There are a couple of real live object-oriented wrappers underway (Python and Java/JNI) so it's high time I published the object schema for these.
Class schema

Areas of functionality

Full usage of the wftk in your application may entail writing some adaptors (this process is covered in the Interface Writer's Guide), but assuming your adaptor needs are already covered and you're not retreating into object orientation, you need to know about the following sections of functionality exposed by the C APIs:


For now, you can look at the code in the command-line utility, but at some point I want to snip some working bits of code out as examples. Most importantly, there are a couple of ways to use wftk that you probably aren't thinking of -- for instance, you can use it as a permission system for arbitrary actions using the wftk_action function. (You can grant or revoke full permission or cause the action to start an approval process; after approval, wftk will automatically complete the action.) WFTK -- it's not just for breakfast anymore.

Copyright (c) 2001 Vivtek. Please see the licensing terms for more information.