Flow/Architecture/Control Flow

From mediawiki.org

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