Note about __perm step. Basic permissions are checked before pipeline start view (e.g 'edit'), as if view were decorated with permission_required decorator. Actualy we're not using decorator, because we need to call our custom deny() method if permissions are not sufficient, but it's not the key. The key is you don't need to check basic permissions in custom __perm method, it's necessary for per-object permissions checks.

Method

Parameters

Result

edit

request, **kwargs 'pk'

{'obj': obj, 'form': {'instance': obj}}

edit__perm

request, **kwargs 'obj', 'form'

pass (None) or PermissionDenied exception

edit__form

request, **kwargs 'obj', 'form'

{'form': form, 'obj': obj, 'form_saved': True}

- form successfully saved

{'form': form, 'obj': obj}

- first open or form contains errors

edit__post

request, **kwargs
'obj', 'form', 'form_saved'

pass (None) by default

edit__done

request, **kwargs
'obj', 'form', 'form_saved'

render template or redirect to
obj.get_absolute_url()

Note, that in general you won't need to redefine pipeline methods, as in many cases custom behavior can be reached with declarative style using options. If you're going too far with overriding views, that may mean you'd better write some views from scratch separate from "smarter".

So, in Getting started example named URLs are 'page-add', 'page-edit', 'page-remove', etc., as we don't provide any custom prefixes and delimiter is '-' by default.

Pipeline example

For deeper understanding here's an example of custom pipeline for 'edit' action. It's not actually a recommended way, as we can reach the same effect without overriding edit method by defining options['edit']['initial'], but it illustrates the principle of pipeline.