I'm happy to announce that I start working on the next generation workflow module, called workflow-ng.
It's inspired by the existing workflow module, but if things go well it's going to be a lot more powerful.
I can use the development as practical work for my study and I will also write my bachelor thesis about this - thanks to the Information & Software Engineering Group of the TU vienna. Furthermore it's great that this all is sponsored by the Austrian company Pro.Karriere!
So, what's workflow-ng?
Workflow-ng ist the next generation module package for building workflows with Drupal. It allows building configurable state machines, which can be supplied programmatically or through the admin interface. So workflow-ng will be a tool for module developers as well as for site admins.
Workflow-ng doesn't work only for content nodes, it will be coded on top of a “drupal entity” - so it will start with support for nodes, comments and users. Furthermore it doesn't urge you to introduce new states for your entities,because it does interpret each saved entity as a new possible state. This allows one to reuse existing information, e.g. reuse the existing „published“ and „moderated“ fields of nodes.
Also workflow-ng won't allow one building state-machines only. One will also be able to react on various “events” with configurable actions, which allows site-admins or modules to adapt any default behaviour. E.g. this suits very well for e-mail notifications. Send a thank you message to the author of a certain node type? Just configure the action and workflow-ng will do it for you.
Read more about it in the concept I wrote: link
Comments
The design looks reasonable.
The design looks reasonable. I'll be interested to see how you tackle some of these subproblems:
DFA/Graph storage: Arbitrary, potentially cyclic, graphs can be hard to store in an RDBMS. I would be interested to know if there are better methods for graph storage. Some places to start might be looking at nested sets (works for trees, though Chx recently proposed an algorithm for storing any Directed Acyclic Graph) and transitive closure tables. I would prefer to see something better than workflow's current adjacency list.
Rules engine/guards UI: I think the UI of the current workflow is a thorny issue. Setting up rules and guards is going to make the UI more complicated. Any thoughts, mockups?
Thats a big project plan, which requires writing workflow and actions -- not to mention modules that already rely on these APIs. What's your first step going to be? Is there a way this work can benefit the goal of getting workflow into core without necessarily requiring all the components to be in place?
Good luck on this project - keep us posted. Will you be keeping your code public for viewing?
thanks
I'll develop all the code in my sandbox, so you can view it there.
ad 1.)
I won't have any graphs.
ad 2.)
yep, that's a good questions. The admin module is the last thing that will be done, so that's one of the last problems I'll tackle. However I've designed some parts in a way, that make it's easier to build an UI..
In particular the UI for the cck field will be needed soon, perhaps I'll have a look at possible javascript enhancements.
ad 3.)
I'll start writing the states module and the pageroute integration for it, because I'll need this soon. Then I'll tackle workflow_ng (conditions, events, and then actions). Regarding core: Workflow-ng will make a lot of things possible without being in core. So I won't work on this, but of course it could be integrated later.. but first of CCK fields and the drupal entity thing has to get in..
I'm looking forward to this module
I'll be very happy to use it when it's ready.