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.

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:name: Category:first → Category:second → Category:third → Category:forth

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>