Flow/Architecture/Control Flow
< Flow | Architecture
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
Attempt to document the basic flow of execution through flow:
Controller edit
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
Why? edit
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? edit
Good Question. Most of what Special:Flow does needs to be accessible from the API calls.
Blocks edit
Think of blocks as individual controllers? They receive an action(request) from a user and
Summary edit
Accepted Actions:
- edit
Topic List edit
Accepted Actions:
- new message - title, content
- mark all read - api call
- add/remove tags
- (un)subscribe to topic
- close
- delete
- oversight
Topic edit
Accepted Actions:
- Reply
- Mark abusive
URL Generation edit
To be figured out soon