Let me give a few notes here as i'm the author of django-viewflow. I stumbled with workflow problems in 2004, wrote simple django-fsm library in 2010, and decide that I could do more in 2013 with django-viewflow.
Common web frameworks like django or flask solves only technical problem related to HTTP/Client/Server functionality and nothing related to business logic organization except simple CRUD support.
It works pretty well if you going to create data entry applications for your business. Data entry applications allows end users to enter the data and do some queries and reporting. Basically you are offer for end user a set of forms for data entry, grid for end user queries and set of reports for things that couldn’t be achieved with simple grid filtering.
The usage pattern for worker is to enter the data, run the query/report and decide what to do next. This style of applications allows unlimited ways for interaction for end users, and adopts many scenarios.
But very fast it became not enough. The breakpoint happens when you came with idea, that you need something like `STATE` or `STATUS` field for one of you entity. This probably happens when you try to organize workers pipeline and collaboration.
And this ruins your well designed CRUD application. Mix of hidden state changes and crazy querying randomly scattered over the code makes hard to have a whole picture what really happens.
After a half of the year, team of 5 developers could produce working but cluttered application that really hard to change to adopt new business process requirements.
The core problem that common web MVC pattern have nothing related to people collaboration. Fortunately there was a lot of research in this field, starting from 198x.
And the answer is - we need an explicit workflow layer (yeah, so pythonic)
You can take a look to http://www.workflowpatterns.com/ It’s pretty formal and hard to read, but it contains set of common patterns that happens when you trying to describe people workflow.
From historic point of view, there was discussion - what is the best way to represent people collaboration visually, what building blocks should be used and etc. In the 2004 there was several popular approaches for this like ebXML, BPEL, and many other formats.
At the 2014 we have the answer - only BPMN products became successful with the time. I think you will not very surprised with this fact, if you will know that BPMN is the only format designed for understanding by humans first. Other formats was designed like bad visual programming language and they are failed.
The core difference of BPMN that you have a gate nodes explicitly separated out of task nodes. This give you unlimited amount of flexibility, and most systems allows to skilled programmer develop very custom gate logic to accommodate all process requirements, embedded into reusable flow building block.
And the last part. The rise of workflow systems happens in the 200x. There was the time when UI-only programs declared as the way to happy user experience. Missing UI tools for system administration was declared as main problem of Linux operation system. Nowadays, UI for administration mostly failed. Today is the rise of script languages like Chef, Salt, Puppet, and DevOps as profession for system administration.
This sort of things became happens even with existing workflow tools, like jPBM based http://camunda.org/
I believe that should happens with any existing workflow software. With good designed library or language for workflow specification, developing application would be faster than any ui programming.
So, as the result of thoughts described above, Viewflow is the library that offers an additional layer for django web framework allows explicitly specify people workflow and takes out the workflow logic from django views.
The future of workflow looks like we will have not only well specified business process but mix of process and cases to accommodate best things from data entry and workflow application styles. There is even existing standard for this - CMMN. And it looks like it would be very soon implemented in many workflow tools.
Common web frameworks like django or flask solves only technical problem related to HTTP/Client/Server functionality and nothing related to business logic organization except simple CRUD support.
It works pretty well if you going to create data entry applications for your business. Data entry applications allows end users to enter the data and do some queries and reporting. Basically you are offer for end user a set of forms for data entry, grid for end user queries and set of reports for things that couldn’t be achieved with simple grid filtering.
The usage pattern for worker is to enter the data, run the query/report and decide what to do next. This style of applications allows unlimited ways for interaction for end users, and adopts many scenarios.
But very fast it became not enough. The breakpoint happens when you came with idea, that you need something like `STATE` or `STATUS` field for one of you entity. This probably happens when you try to organize workers pipeline and collaboration.
And this ruins your well designed CRUD application. Mix of hidden state changes and crazy querying randomly scattered over the code makes hard to have a whole picture what really happens. After a half of the year, team of 5 developers could produce working but cluttered application that really hard to change to adopt new business process requirements.
The core problem that common web MVC pattern have nothing related to people collaboration. Fortunately there was a lot of research in this field, starting from 198x.
And the answer is - we need an explicit workflow layer (yeah, so pythonic)
You can take a look to http://www.workflowpatterns.com/ It’s pretty formal and hard to read, but it contains set of common patterns that happens when you trying to describe people workflow.
From historic point of view, there was discussion - what is the best way to represent people collaboration visually, what building blocks should be used and etc. In the 2004 there was several popular approaches for this like ebXML, BPEL, and many other formats.
At the 2014 we have the answer - only BPMN products became successful with the time. I think you will not very surprised with this fact, if you will know that BPMN is the only format designed for understanding by humans first. Other formats was designed like bad visual programming language and they are failed.
The core difference of BPMN that you have a gate nodes explicitly separated out of task nodes. This give you unlimited amount of flexibility, and most systems allows to skilled programmer develop very custom gate logic to accommodate all process requirements, embedded into reusable flow building block.
And the last part. The rise of workflow systems happens in the 200x. There was the time when UI-only programs declared as the way to happy user experience. Missing UI tools for system administration was declared as main problem of Linux operation system. Nowadays, UI for administration mostly failed. Today is the rise of script languages like Chef, Salt, Puppet, and DevOps as profession for system administration.
This sort of things became happens even with existing workflow tools, like jPBM based http://camunda.org/
I believe that should happens with any existing workflow software. With good designed library or language for workflow specification, developing application would be faster than any ui programming.
So, as the result of thoughts described above, Viewflow is the library that offers an additional layer for django web framework allows explicitly specify people workflow and takes out the workflow logic from django views.
You can take a look for shipment views example, when I start i didn’t expect that so complex workflow could be exality extracted out of the views - https://github.com/viewflow/viewflow/blob/master/tests/examp...
The future of workflow looks like we will have not only well specified business process but mix of process and cases to accommodate best things from data entry and workflow application styles. There is even existing standard for this - CMMN. And it looks like it would be very soon implemented in many workflow tools.