Topic: wftk -- Process definition:
[ wftk home ]
[ process definition ]
[ discussion ]
|
(2/23/00) This is basically a total rewrite after some thought and feedback from
Thomas Fricke.
Data storage is an extremely central concept to the workflow, of course. As I get further into the design, it's becoming obvious that the value sheet is going to play a central role in defining each active process. Each variable is represented by some value in the value sheet. (And the value sheet is also the logical place to keep information about the state of the process, but that's a discussion for another time.) A value is essentially a piece of text, because it's textually represented inside a tag in the value sheet. A type adapter knows how to impose certain semantics and perform certain operations on the textual value. Type adapters might include integer, money, time, date, string, pattern, or whatever. They might be parameterized, so that enumerations could be supported. There is quite a lot we can do with the adapter concept, without necessarily having to do it all at once up front. We also need to be able to get to data which is stored elsewhere. So I am introducing the idea of a storage adapter which leaves status information in the value sheet (whatever it needs to get to the actual data). Storage adapters might include PostgreSQL, Sybase SQL Server, FileNet document management, the filesystem, the default (value sheet), ODBC, and so forth. We can easily imagine adapters written to take advantage of new storage techniques. The point of storage adapters is that storage outside the database allows interaction at the data level with other processes and systems. This interaction goes both ways, so that we can read database information, store documents, etc.
OK. In addition to simple values, I think we need at least two aggregates: the record and
the collection. And in fact I suspect we can get away with a single aggregate construct
that allows us to define records or collections in a single construct. But first,
let's look at the basic
First complication, then, would be structures. The value of record fields can be accessed with the usual dotted notation, so that the text value above would be referred to as ${stuff.field1}.
I had considered taking liberties with our So a storage adapter will be able to represent records which are stored elsewhere. Ideally such storage units would be possible to nest, so that for instance a serialized version of a structure could be created using one storage adapter, then that serialized object be treated as some raw data to be stored somewhere using another storage adapter. This is obviously far out of scope of the original project, but it's a powerful idea. I hope I'll get back to it before the year's out.
If we have a common data structure that we know we'll be reusing, we can define it with
the
So how do we do storage? Let's say something like this: In the case where a record or table is used from a relational database, the data structure is understood to be implicitly defined by the database system. The storage adapter for that database is responsible for translating the database's columns into usable typed data.
We're still not quite done with the data tag. We want some additional modifiers as well.
First, the
Then we'll want a So this data stuff looks like it's coming together. |