Extension talk:Workflow.php

This talk page pertains specifically to the development of this extension. For more general discussion about bugs and usage etc, please refer to the mediawiki.org talk page at MW:Extension talk:Workflow

Overview

Eventually we'd like to support many work-flow related features in the wiki, but the first and most important is to create the simplest possible means of moving articles from one point in a workflow sequence to another. To do that a parser function called "tag" has been created which allows predefined groups of content to be quickly cycled though without needing to edit the containing article.

This extension code consists of two main aspects:

• the parser-function rendering which includes the javascript for switching between states when clicked, and for making the AJAX requests to update the state after a delay.
• the response which includes updating one of the tag's template definitions in the article and returning the article's category-links

• Should enforce convension of Category:Name = Template:Value, which only allows category named parameters to work with template transcluded values.
• Make use of the

  <div id="catlinks">... </div>

  area to add additional workflow category information.
• Need to define some simple examples.

Usage Syntax

The idea with the syntax is to enforce a solid convention for the way workflow is approached as an overall system rather than offer flexibility od syntax to suit many diverse uses. The general syntax is as follows (the parameter is optional and will default to the first state):

{{#workflow:Job|In progress}}

The article Workflow:Job contains a bullet list of article titles each of which forms a specific phase in the workflow. The workflow extension is hard-wired to categorise the article into Category:Title (where "Title" is the currently selected state in the cycle), and to transclude Template:Title. Using the Category and Template name-spaces here is not optional, it is designed to enforce a consistent method usage of the workflow system which is extremely important when using a wiki for organisation. In the example above, the content of Workflow:Job might be as follows:

*[[Category:Lead]]
*[[Category:Quote]]
*[[Category:In progress]]
*[[Category:Complete]]
*[[Category:Invoiced]]
*[[Category:Paid]]

By using the Workflow namespace, and enforcing the strict use of Category and Template with that title (in a similar way to how the MediaWiki software uses the Talk namespace in specific way) it allows us to later extend the way other namespaces are used with workflow items, for example to allow phases to contain automation scripts, unit tests or other context-specific meta-data.

Example 1

Switching between two binary states 1/0, on/off, yes/no. This may or may not categorize as it switches between states

This will categorise the items into Category:Yes and Category:No because we're enforcing the convention of the name of each state being a category. --Nad 10:43, 23 October 2007 (NZDT)

• Yes
• No

Parser function call

{{#tag: Yes = ...|No = ...}}

Example 2

An example sequence of three states in a workflow, Category:First state, Category:Second state, Category:Third state.

Extending Category Info

The category links information below the article content can be thought of in a more general sense as the information about the current article's relationships to other articles.

Semantic MediaWiki's "facts" section below the article is in the same place, except that it is rendered as part of the article's content which we feel is wrong because it's conceptually outside the content not part of it. Another way to look at it is that information about the article which is not explicitly part of the article's content should not be returned by a request which uses the render action.

The workflow sequences that an article is a part of is also a very important aspect of its relationships, and the extension should add this information to the catlinks area using the following syntax (except that the namespaces wouldn't be displayed):

Wokflow:Job: Category:Lead → Category:Quote → Category:In progress → Category:Complete → Category:Invoiced → Category:Paid

The catlinks can be extended by overriding the getCategoryLinks method of the user's skin object if one exists.

The AJAX Response

The response to the AJAX requests requires a tag in the article to have its state updated, and for the category-links part of the rendered page to be returned to the client. To get the properly rendered category links, the parser needs to be instantiated and the page rendered, so the normal AJAX dispatcher must be bypassed since it is used to return data before instantiating the main article environment. The following code is called at start-up to achieve this. As can be seen it enables the two other aspects of the code, which are handled in their own functions described below. <php> if ($wgUseAjax && $_REQUEST['action'] == 'ajax' && $_REQUEST['rs'] == 'wfWorkflowUpdateTag' && is_array($_REQUEST['rsargs'])) { list($_REQUEST['title'],$wgWorkflowTagID,$wgWorkflowTagState) = $_REQUEST['rsargs']; $wgHooks['OutputPageBeforeHTML'][] = 'wfWorkflowReturnCatlinks'; $wgWorkflowUpdateTag = true; $_REQUEST['action'] = 'render'; } else $wgWorkflowUpdateTag = false; </php>