Programmer's Guide to the wftk
[ wftk documentation home ]
Overview
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:
- Site definition structure (for repository manager configuration)
- List definitions
- Publishing formats
- Datasheets = list objects
- Process definitions (procdefs) and ad-hoc workflow description
- Task objects
- Request objects
- User objects
- Notification (alert) objects
- List (query) objects
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:
Examples
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.