albert boulanger wrote:
Kapil Thangavelu <kthangavelu@earthlink.net> wrote:
The PTK has been undergoing radical changes as of late. Its worth taking another look at as the current design is much more supportive of alternative workflow designs.
Disclamer: This is my gleaming -- I could be off. I have done a keyword search on the Zope-PTK list for workflow to understand the recent discussion on workflow design within PTK. It seems to me that workflow is tied to strongly with documents in the design plan. In the model of workflow being discussed there, documents march through workflow steps. What if a workflow step is a computation and requires multiple data sources to be done? Instead, a workflow step needs to have an explicit representation with data items (documents) associated with it having some kind of version info associated with them. This need comes from the use cases that I deal with in setting up workflow for science and engineering computation.
For a good review of workflow requirements see:
http://www.ics.uci.edu/pub/endeavors/docs/AdvancedWorkflow.pdf
i haven't had time to read through the links, although i will once i get some more of that mystical free time stuff, but i wanted to clarify about PTK workflows. most of the existing workflow structs in PTK were doc based with simple workflows, but there has been a concerted effort to refactor PTK into Singleton objects which give abilities to all objects vs. the old method of inheritance for abilities. In this scenario workflow objects can be plugged into the architecture. Another item that gives support for complex workflows is the event/subscriber/publisher system being developed right now. check out the later half of the PTK archives for August to get some more background. if you want to influence the project, now is the time, make your voice/needs heard. Cheers Kapil