[Zope-CMF] Project-style workflows, DCWorkflow, SQL, etc.

[Phillip J. Eby]

At 02:21 PM 10/12/01 +0200, Ulrich Eck wrote:
>As far as I can see right now, it would be good to create a new tool
>e.g. portal-activity/portal-task or whatever it will be called.
>
>This tool holds different process-definitions and is based on the
>portal-worklfow-tool (optimally the interface could be used
>without major modifications).
>
>I see the activity-tool as a coordinator for Application-objects
>that internally use the portal-workflow (DCWorkflow/hardcoded ...).
>
>The activity-tool leads the participant to the application/task which
>is finished when it reaches a certain state. Then transitions defined
>in the activity-tool can be made (manually/automatically).
>
>Worklists can be used to determine which activities are open depending
>on the participants information of a ProcessDefinition.
>
>A participant can be a person/group/machine.
>
>Does this alltogether make sense ??


Not to me, but I'm probably blinded by viewing this through the lenses of 
my "waiter-for" model perspective.  What you're saying above sounds like 
overkill to me, as I don't think it's necessary to modify the existing CMF 
at all in order to do more complex workflows.  At most, DCWorkflow might 
need some extra features, but I'm not sure even that would be necessary.



> > >How is WarpCore doing? Been too busy to keep up with it.
> >
> > I've been too busy to work on TransWarp much lately.  WarpCORE has long 
> ago
> > been in production use as a base schema for our Sybase application
> > databases, however, and Ty has made prototype versions of the WarpCORE
> > kernel schema for Firebird/Interbase and PostgreSQL.  I've also begun a
> > draft of documentation for the WarpCORE design patterns and kernel, but
> > have no schedule for completing it.
> >
>
>1. What exactly is WARPCore?
>2. Is there some code that I could see to find out what it does ?? I'm 
>searching
>for a Relational<->Object Binding and would contribute a shema for
>SAP-DB if possible.

Here's the "Overview" section from the documentation...  which is in fact 
all I've written so far.  Any further discussion of WarpCORE should 
probably go to the TransWarp list, which I've cc:'d on this e-mail, since 
it has little relevance to the CMF.

======

Overview

WarpCORE is a set of patterns for implementing "business object" 
applications in relational databases.  Truly implementing business objects 
requires not only "object" concepts like classes, polymorphism, interfaces, 
and object composition, but also "business" concepts such as relationships 
and historical event records.  Further, creating practical applications 
usually requires interaction with "legacy" applications or other 
systems/databases which are not a part of the new application.

WarpCORE addresses most of these requirements with only a few tables and 
stored procedures.  A typical base WarpCORE implementation, depending on 
the specific database platform, may need as few as 7 tables and 13 stored 
procedures, many of which can be eliminated if they are not needed for that 
application.  WarpCORE is also highly cross-platform, with production DDL 
already in existence for Sybase, and prototypes written for 
Interbase/Firebird, and PostgreSQL.  Porting to other databases (as long as 
they have transactions and stored procedures) should be straightforward, 
since WarpCORE tends towards least-common-denominator SQL features.

Unlike many object-relational approaches, however, WarpCORE still allows 
for very high-performance applications, by leveraging the relational 
database's strengths.  WarpCORE uses a "table per interface" approach which 
allows each interface to have indexes specifically tuned for that 
interface's requirements.  It also uses a stored-procedure manipulation 
pattern that makes it easy to hide any denormalizations introduced for 
performance enhancement.

Although the creators of WarpCORE prefer using Python to most any other 
language, and mostly develop web applications, there is nothing 
particularly Pythonic or web-oriented in WarpCORE, as it is a set of design 
patterns for relational databases, not applications per se.  (There are a 
few fields in the standard "tw_classes" table which are useful for 
web-based applications, but their use is subject to application 
interpretation anyway, so there's nothing stopping you from using them for 
something else or omitting them altogether.)

Indeed, WarpCORE databases are quite usable from other languages besides 
Python.  For example, Java offers many object-relational mapping libraries 
that should work without modification against WarpCORE databases, once the 
appropriate mappings are defined.  For example, ArsDigita's ACS system 
includes a "persistence definition language", PDL, which is rather ideally 
suited to using WarpCORE objects for persistence.  By contrast, PyDO, the 
closest equivalent to PDL available for Python, would require quite a bit 
of extension to work well with schemas based on WarpCORE, or at minimum the 
addition of extra views to the schemas.  We hope to remedy this situation 
in the future by creating a TransWarp "horizontal framework" for mapping 
Python objects to/from WarpCORE database schemas.

======

So, as you can see, WarpCORE is *not* an O-R binding or mapping tool, it's 
a set of modelling patterns for schemas, a set of idioms for organizing 
data.  If I document it well, I think it will turn out to be a full-blown 
"pattern language".  But it's not software, even though at some point 
TransWarp will evolve to include code that's specialized for use with 
schemas modelled with it.  Currently, the single production WarpCORE 
application is actually based on Zope+ZPatterns, but Ty and I have just 
begun work on porting it to ZLite+TransWarp.  This should result in 
enhancements to both ZLite and TransWarp, probably including some kind of 
database mapping tools, since the target application has both 
WarpCORE-on-Sybase and LDAP datasets that it works with.