Difference between revisions of "Extension talk:Treeview5.php"
(update) |
(→How it works: notes) |
||
| Line 30: | Line 30: | ||
1{uniq}-{id}-{depth}-{item}2{uniq} | 1{uniq}-{id}-{depth}-{item}2{uniq} | ||
Where ''uniq'' is a unique string representing treeview's in general, ''id'' is a unique string representing the current tree, ''depth'' is the depth of the current row with respect to the current tree root, and ''item'' is the wikitext within the current row. Each row is converted to the new structured format by the private ''formatRow'' method. The information is "protected" from the parser merely by the fact that it contains no markup characters, but this could be made more robust later. | Where ''uniq'' is a unique string representing treeview's in general, ''id'' is a unique string representing the current tree, ''depth'' is the depth of the current row with respect to the current tree root, and ''item'' is the wikitext within the current row. Each row is converted to the new structured format by the private ''formatRow'' method. The information is "protected" from the parser merely by the fact that it contains no markup characters, but this could be made more robust later. | ||
| + | |||
| + | '''''NOTE 1:''' If the same article is transcluded more than once it may not get processed again after the first time. This caching effect occurs at an internal level within the parser and is not affected by globals or parser properties. This means that information relating to specific items or sub-tree's could be repeated across transcluded instances of the same article within one or more trees in the page. This is not a problem in the case of the tree-id because only id's of root trees will be used in the final rendered tree.'' | ||
| + | |||
| + | '''''NOTE 2: There a potential problem which hasn't been tested yet, with a sub-tree being transcluded twice in consecutive nodes. The tree id is also used to determine when a new tree is starting (by checking if ''id'' has changed), so the repeated id problem arising from multiple adjacent transclusion would prevent the loop from knowing about the transition from one of the similar sub-trees to the next.'' | ||
After the resulting structure has been parsed, the content portions will have been converted into HTML and the information portions remain unchanged. Below is the HTML source of the above example after parsing and printed at the start of the ''renderTree'' method (the ''ParserAfterTidy'' hook). | After the resulting structure has been parsed, the content portions will have been converted into HTML and the information portions remain unchanged. Below is the HTML source of the above example after parsing and printed at the start of the ''renderTree'' method (the ''ParserAfterTidy'' hook). | ||
Revision as of 02:25, 3 March 2008
|
Treeview5.1 is a new approach to the core recursive bullet-list code which doesn't require any voodoo, and should be compatible with all MediaWiki versions including 1.12.
Parameters
- root:
- id:
- openlevels:
Livelets
The new tree doesn't currently work when included via AJAX because the code in the response is not executed. The livelets code should be updated to execute script tags within responses.
How it works
The initial problem was how to write a parser-function which could generate a tree which could be composed of other transcluded tree's (i.e. parser-functions which are recursively executed forming a larger whole structure together). This seemed impossible since there are no MediaWiki properties available in the environment which reveal the current depth that the parser-function expansion is operating at.
But after thinking about the problem more closely, it turns out that the tree can be constructed without depth information by converting each tree row into a new format containing depth and tree id information which is protected from wiki-parsing. This information can then be converted into tree JavaScript after the parser has finished in the ParserAfterTidy hook.
Here is the wikitext of an example tree which includes two transcluded tree's
*[[toplevl]]
**bar
***baz
*foo
**[[Bar]]
***{{:Foo}}
**[[Baz]]
***{{:Bar}}
The expandTree method (the #tree parser-function hook) then converts all the matched rows into the following general structure:
1{uniq}-{id}-{depth}-{item}2{uniq}
Where uniq is a unique string representing treeview's in general, id is a unique string representing the current tree, depth is the depth of the current row with respect to the current tree root, and item is the wikitext within the current row. Each row is converted to the new structured format by the private formatRow method. The information is "protected" from the parser merely by the fact that it contains no markup characters, but this could be made more robust later.
NOTE 1: If the same article is transcluded more than once it may not get processed again after the first time. This caching effect occurs at an internal level within the parser and is not affected by globals or parser properties. This means that information relating to specific items or sub-tree's could be repeated across transcluded instances of the same article within one or more trees in the page. This is not a problem in the case of the tree-id because only id's of root trees will be used in the final rendered tree.
NOTE 2: There a potential problem which hasn't been tested yet, with a sub-tree being transcluded twice in consecutive nodes. The tree id is also used to determine when a new tree is starting (by checking if id has changed), so the repeated id problem arising from multiple adjacent transclusion would prevent the loop from knowing about the transition from one of the similar sub-trees to the next.
After the resulting structure has been parsed, the content portions will have been converted into HTML and the information portions remain unchanged. Below is the HTML source of the above example after parsing and printed at the start of the renderTree method (the ParserAfterTidy hook).
1tv47cb2fd61165f-47cb2fd6dadf4-0-<a href="/wiki/index.php?title=Toplevl&action=edit" class="new" title="Toplevl">toplevl</a>2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6dadf4-1-bar2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6dadf4-2-baz2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6dadf4-0-foo2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6dadf4-1-<a href="/Bar" title="Bar">Bar</a>2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6dadf4-2-1tv47cb2fd61165f-47cb2fd6da03a-0-<a href="/Foo" title="Foo">Foo</a>2tv47cb2fd61165f2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6da03a-1-bar2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6da03a-2-baz2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6da03a-0-foo2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6da03a-1-biz2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6da03a-2-1tv47cb2fd61165f-47cb2fd6d9c40-0-<a href="/Bar" title="Bar">bar</a>2tv47cb2fd61165f2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6d9c40-1-baz2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6d9c40-2-biz2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6da03a-1-<a href="/wiki/index.php?title=Baz&action=edit" class="new" title="Baz">Baz</a>2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6dadf4-1-<a href="/wiki/index.php?title=Baz&action=edit" class="new" title="Baz">Baz</a>2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6dadf4-2-1tv47cb2fd61165f-47cb2fd6d9c40-0-<a href="/Bar" title="Bar">bar</a>2tv47cb2fd61165f2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6d9c40-1-baz2tv47cb2fd61165f 1tv47cb2fd61165f-47cb2fd6d9c40-2-biz2tv47cb2fd61165f
The following regular expression is used to create an array, $matches, each item of which contains a list of (,$id,$depth,,$icon,$item) extracted from the formatted rows in the page.
Following this extraction of row information into $matches is a loop that builds a new list called $rows which contains more detailed information about the rows than $matches, and adjusts the depth values to account for transclused sub-tree's. The $rows array is a list of ($id,$depth,$icon,$item,$start). $id is the id of each root-tree, $start is a boolean indicating whether or not the row is the first in a new tree.
The main dTree JavaScript can then be constructed by looping through the $rows list and converting ordered depth-based information to the parent/child format required by dTree. The index into the $rows array is used as the dTree node identifiers.
Root tree's and sub-tree's
One of the difficulties with this extension has been to do with the difficulty in assessing from within a parser-function whether or not it's at the root level in terms of transclusion-depth. The new version doesn't require voodoo to determine this, it instead does the following pattern match on all the formatted rows in the page after wiki-parsing is complete (in the ParserAfterTidy hook).
This results in an array called $subs[1] which contains all the tree id's which are not transcluded. It does this by checking which rows have a preceding minus symbol, since top level ones will all be preceded by a p tag or a line start (see the example output of formatted rows above). An id is at root level if it is not in the $subs[1] array. This way is not as robust as it could be, and is also more computationally intensive than it could be.
See also
- dTree (javascript based)
- Slipstream wp-Dtree (php based)
