Proposals for workflow framework

Минималистичный, простой и гибкий в использовании workflow фреймвок (возможно, workflow в некоем своем понимании.)
В данный момент - для использования в построении модуля registrations как абсолютно гибкой и настраиваемой как угодно системы регистрации пользователей.

Идея:
  - класс Workflow;
  - подписные адаптеры(subscriber'ы) - правила (они же - статусы workflow).

Реализация:
  - Есть абстрактный класс Workflow, имплементирующий свой интерфейс, и предназначенный для подмешивания в любые другие классы, которые могут быть как локальными, так и глобальными утилитыми (зарегистрированными своим интерфейсом, но не IWorkflow, для workflow-функционала это и не нужно), а могут быть вообще не утилитами, а простым контентом или еще чем угодно. Короче, что-то, что мы хотим сделать "типом" workflow. Им - передаем в метод handle(doc) документы. Что именно делать с документом, Workflow решает сам в зависимости от статуса документа и определенного порядка правил workflow.
  - Соответственно, правила (WorkflowRule) суть подписные адаптеры, зарегистрированные на тот интерфейс, который предоставляет объект, основанный на Workflow.
  - Сам Workflow читает список зарегистрированных конкретно для него workflow rules подписчиков и можно выстраивать их в нужном порядке (zope.schema.List -> zope.schema.Choice + vocabulary).
   - при передаче в него какого-либо объекта, с которым можно и нужно что-либо делать, вызываются workflow rules в том порядке, который определен (программно или через форму).
   - таким образом, каждый раз, вызывая "handle(obj)" метод, его обрабатывает только один, очередной подписчик и сохраняет (в аннотации) статус.
   - для каждого статуса есть метод start, вызываемый когда его обрабатывает этот подписчик, и метод stop, вызываемый, когда его обрабатывает следующий по определенному порядку подписчик.
   - можно форсировать порядок, передав напрямую имя правила (подписчика). В этом случае порядок сохранится, но будет следовать (для данного документа) с нового правила и далее по обычному порядку.

Зависимости:
  - модуль ice.app.workflow получается независимый от всего остального что есть в ice.app. Но он настолько мал, что нет смысла выводить его в отдельное яйцо.

  - однако, в административном скине можно построить специальный вид - таблицу, в которой видны все существующие виды workflow в одной куче, и, выбирая их, можно настраивать правила и порядок их использования. Правда, для этого придется все workflow типы как-то зарегистрировать. Если сделать предположение, что это локальные утилиты, (как, например, уже существующая утилита для регистрации пользоватлей), то придется их добавочно регистрировать по интерфейсу IWorkflow.
Однако это решение пока мне не очень нравиться, надо как-то подругому выискивать все типы workflow, потому что это могут быть и не утилиты, и вообще не локальные объекты.
Правда, если они не локальные, то и порядок workflow rules не отредактируешь через форму.