Viewflow 0.12 upgrade instruction

README.rst

Viewflow 0.12 upgrade instruction

1. Django 1.6 is no longer supported. please consider upgrading.
2. Process wait-lock was removed for all locks implementation. Django 1.8 users need to enable django-transaction-hooks that required by celery.Job task. Any 3rd party task queue implementation should use transaction.on_commit to schedule a background task.
3. Django and DjangoRestFramework tend to use _class suffix for the variable names. Viewflow now follows the same naming theme. All _cls suffixes were renamed to _class. Check your code for the process_cls, task_cls and flow_cls variables and rename to process_class, task_class, flow_class respectively.
4. Django-Extra-Views integration was removed. Consider using django-material or django-super-forms packages to simplify forms handling.
5. @flow.flow_view and @flow.flow_start_view decorators no longer works with class based views. Remove parentheses from the decorator usage, and use @method_decorator for your class based views
6. activation no longer passed as an explicit parameter to the views. Use request.activation. That follows the same agreement, as we have for request.user`(django) and `request.data (restframework). self.activation in the built-in views is still available.
7. viewflow.views package was moved to the viewflow.flow.views. View names itself was changed. See the comments below for the renaming samples.
8. If().OnTrue().OnFalse() renamed to If().Then().Else()
9. All conditions in If, Switch and other nodes receives now a node activation instance instead of process. So you can gen an access to the current task via activation.task variable.
10. Same for callable in the .Assign() and .Permissions definitions.
11. 'task_loader' not is the attribute of a flow task. In makes functions and signal handlers reusable over different flows.
12. Flow namespaces are no longer hardcoded. Flow views now can be attached to any namespace in a URL config.
13. @flow_start_func, @flow_start_signal decorators need to be used for the start nodes handlers. Decorators would establish a proper locking avoids concurrent flow process modifications in the background tasks.

Functional based views migration sample

- @flow.flow_view()
- def my_view(request, activation, **kwargs):
-     process = activation.process
+@flow.flow_view
+ def my_view(request, **kwargs):
+     process = request.activation.process

Class based view migration sample

- from viewflow.views import StartViewMixin
-
- class MyView(StartViewMixin, generic.CreateView):
-     @flow.flow_view()
-     def dispatch(request, activation, **kwargs):
-          ...
+ from django.utils.decorators import method_decorator
+ from viewflow.flow.views import StartFlowMixin
+
+ class MyView(StartFlowMixin, generic.CreateView):
+     @method_decorator(flow.flow_view)
+     def dispatch(request, **kwargs):
+          ...

View names migration sample

- from viewflow.views import ProcessView
+ from viewflow.flow.views import UpdateProcessView

- from viewflow.views import StartProcessView
+ from viewflow.flow.views import CreateProcessView

- from viewflow.views import StartViewMixin, TaskViewMixin
+ from viewflow.flow.views import StartFlowMixin, FlowMixin

- from viewflow.views.task import AssignView
+ from viewflow.flow.views import AssignTaskView

If node migration sample

- check_status = flow.If(
-     lambda process: process.completed
- ).OnTrue(this.end).OnFalse(this.repeat)
+ check_status = flow.If(
+    lambda activation: activation.process.completed
+ ).Then(this.end).Else(this.repeat)