Hardik--
let me re-iterate my "Shopping List" example:
In this (imaginary) workflow, we start with a request to GET a list of supply
items:
/supply/item/wf_id=reqitems
This initiates a new workflow "reqitems" - S3Request.__call__ will detect the
"wf_id" and hand over to the workflow engine, which executes the request in the
context of the workflow.
Normally, /supply/item just gives you a list view of supply items - it's not
leading anywhere.
But with the workflow identifier in the URL, this presents a list view of supply
items *plus* additional action items:
1) an action button for each record to add it to the "shopping list"
2) a menu to see the currently "selected" items with option to "deselect" them
again
3) a button "Request these items"
So, if the user clicks on a "Add to shopping list" button, then this initiates
a request to
supply/item/4?wf_id=reqitems:1&wf_action=select
(This time it has an instance-ID for the workflow)
Again: the S3Request detects the workflow qualifier and hands this request over
to the workflow engine for processing.
If the user clicks on "Request these items", then this button links to
GET req/req/create?wf_id=reqitems:1
And again, S3Request detects the workflow qualifier and hands the request over
to the workflow engine. This will return a req/req create-form that is
prepopulated with the previously selected items. The user can fill in this form
with the request details, and then submit to
POST req/req/create?wf_id=reqitems:1
And again, this goes to the workflow engine which now creates the new request.
None of the requests ever goes to a dedicated workflow-controller - but through
regular RESTful controllers. That is, the opposite of what you did:
Instead of:
/workflow/index?c=supply&f=item&wf_id=req_items
we call:
/supply/item?wf_id=reqitems
This has a lot of advantages:
a) controller settings can be applied even by the workflow engine, e.g. you
have the prep and postp of that controller available
b) controller-based authorization rules apply automatically
c) you get the right S3Request/S3Resource combo - no need to "fake" anything
d) you get the right menu/breadcrumbs status
The tricky part is to connect the steps by rendering the action items into the
page, and to realize the interim data storage (e.g. the "list of selected
items").
What we need right now is:
a) tweak of S3Request.__call__() to call the workflow engine if the request is
addressed at a workflow
b) the workflow engine to instantiate the respective workflow (or return to the
regular S3Request if no such workflow can be found)
c) a configuration pattern for workflows: this can be a Python-class pattern for
now like workflow_x = S3WorkflowNode(...) & S3WorkflowNode(...) &
(S3WorkflowNode(...) | S3WorkflowNode(...))
If we have that, we have to discuss how we match a request to the right
workflow node, and how we store the current workflow status.
And then we discuss a framework how we render workflow action items into the
page.
Once all this works, we can discuss how to serialize workflows to store them in
the DB (or export/import them via XML) - but for now we really need the engine
first.
The key people I know who are keen to implement workflows in Eden are all
Python-capable - and only when they are happy, we extend it beyond that
audience.
Dominic
torsdagen den 27 juni 2013 00.47.29 skrev hardik juneja: