Attempt to document the basic flow of execution through flow:
All requests start at Special:Flow. The code for this special page will:
- Figure out which article title the request is asking for.
- Figure out which workflow definition is being used against this article title
- Figure out what type of action is being requested by the user(view/reply/suppress/etc?)
- Use the article title and workflow definition to locate the appropriate flow object
- Provide the article id and the user id to the sharded database implementation
- Create a controller class capable of performing actions for the current workflow
- Pass execution off to the controller
Most work within flow will be done by Blocks(think widget). The Controller will:
- Create all the blocks referenced by the definition
- Apply the users action(ex. edit) to all the blocks, along with appropriate POST data
- If all the blocks accepted the users action then commit the blocks.
- Issue a redirect to 'view' action after commit
- Render all the blocks
Special:Flow is intended to bootstrap flow.
The controller is intended to orchestrate the block implementation.
The rendering portion should be seperate from the form handling in
What about API calls?
Good Question. Most of what Special:Flow does needs to be accessible from the API calls.
Think of blocks as individual controllers? They receive an action(request) from a user and
- new message - title, content
- mark all read - api call
- add/remove tags
- (un)subscribe to topic
- Mark abusive
To be figured out soon