wftk: Python OO wrapper

This is a set of Python classes for wftk. It builds on the wrappers for the XMLAPI, the repository manager, and the wftk core API. Since Python is indentation-sensitive, and the LPML is indentation-challenged, if you change this source, be sure not to break up indentation blocks without preserving indentation very carefully.

So. Let's first output a handy comment block.

#######################################################################################################
#
# This is a Python implementation of the wftk class schema.  It is the first such implementation.
#
# Copyright (c) 2002-2006, Vivtek, and released under the GPL.
#
#######################################################################################################

Our importation needs are pretty minimal; we import our wrappers, and that's about it. Note that the wftk core wrapper isn't written yet, so we don't import it yet. (See how this all makes sense?)

import repmgr
import xmlapi
import copy
from types import *
from string import * # This is only here for the cmdline parser implementation.  TODO: remove if that's gone into the C library.

The "types" module provides a few handy utilities for talking about types when looking at data coming in. Actually, at the moment I don't think I'm using it. I might take it back out at some point.

We define one error, ParseError, which I raise when a parse command results in a parse error. The details of the error get passed out of the wrapper, and we toss it right into the error we raise. Neat stuff.

ParseError = "Error parsing XML"

The structure of the wftk class schema is pretty simple, and falls into two basic sections: low-level local data handling (XML and xmlobj classes) and higher-level system interaction (starting at the repository class).

All data in the wftk is treated as XML data; this is manipulated using the XMLAPI library, which is wrapped in the "xml" class:

See xml: XMLAPI data structure

Record-like data in the wftk is treated as a special case of XML, the "xmlobj", which defines field access on top of the XMLAPI library. The xmlobj class subclasses xml:

See xmlobj: XML-based record object

System interaction begins with the repository, which represents a system. The repository organizes all its data into lists, each of which have entries. Most action in a repository happens at the entry level, since that's where the data is actually stored. The entry has field values and optionally can have attached files; when an entry is added, deleted, or changed then the system can take arbitrary action, either via the publishing machinery (writing pages for later consumption on a website) or via the workflow machinery (creating tasks, doing data manipulation, sending notification, and so forth.)

See repository: the system
See list: a data source
See entry: an individual list entry

On top of all this, the wftk base class also defines a rudimentary command-line interface framework. This is used by the wftk GUI classes and will also eventually be used by the SOAP server, I suppose.

See cli: a command-line interface definer

Likely further extensions to this class structure are as follows, but I'm feeling this out as I go.

TaskWhen I retrieve an entry from a list of tasks, the result is not just an entry, it is a task. Primarily this means that in addition to doing entry-specific things to it, I can also complete it, rescind it, and so forth.
ProcessI'm not yet sure that a process requires a separate object. Each entry in a list in the repository manager has workflow aspects, and is thus a process (the list in the repmgr is actually an elaboration on the dsrep of the wftk core API). So a process object may simply be superfluous.
QueryQueries will certainly be required; a query is passed to the repmgr to return selected ranges of objects. This may be turned into SQL, or it may be used to search a directory, or whatever is appropriate for the list adaptor used by the list in question.
AttachmentAttachments are document-sized, optionally versioned values in entries. Document management, folks.
ProcdefIt seems really logical to build procdef-specific manipulation into a nice object, even though there aren't any procdef-specific API calls in the wftk yet. This sort of thought is why it's always nice to switch development languages and paradigms.

This code and documentation are released under the terms of the GNU license. They are copyright (c) 2002-2006, Vivtek. All rights reserved except those explicitly granted under the terms of the GNU license. This presentation was prepared with LPML. Try literate programming. You'll like it.