User:Lord Farin/Long-Term Projects/Extension

= Motivation =

On this page I will describe the ideas I have pertaining an extension of PW which will allow for more consistent style, easier transclusions and general ease of use. To this end, I seek to develop (together with Joe) a set of custom tags, maybe namespaces and templates to accommodate for this.

Of course, for this project to be viable, documentation needs to be extensive, and Help:Editing will need serious expansion/adaptation.

Feel free to comment and/or contribute ideas/prototypes.

= Progress/Overview of Ideas =

Rigour in Page Style
In order to achieve maximal consistency, it will be a good idea to add tags like:

Maybe more can be thought of. These will go with possible HTML attributes (and default values, of course); for example:

title="Section Title" foldable="folded/unfolded/false" headerlevel="2/3/4..." sectionname="For transclusion reference; eg. 'proof1'"

Furthermore, ideally users could set preferences (like 'by default, expand all folded sections').

This basically comes down to a DOM structure.

Transclusion
My currently most viable idea to achieve rigour in transclusions is the introduction of the tag or parser function Title of page whose section must be transcluded

It will be endowed with further attributes as deemed necessary/possible.

I strive for the possibility to adjust the heading level of all stuff inside the transcluded tag automatically, avoiding the struggle now often encountered.

A snippet of PHP that increments all headers in the input string $subject by the positive integer $increment: function fnPWadjustHeadings($subject, $increment){ //Some input checking might be necessary, I skip it for now

if($increment <= 0){ return $subject; }

$eq = ""; $i = 0; while($i < $increment){ $eq .= "="; $i++; }

$result = preg_replace('#={2,}#', '$1'.$eq, $subject);

return $result; }

Unfortunately, parser functions do not naturally support named parameters. However, it is possible to work around this, as I have found out. Compare the   function; fortunately, after the first parameter (the page name), only named parameters will be necessary. This means I can build a lot of the code on the implementation of that function.

It appears that parser functions really should be time-invariant constructs, according to MediaWiki documentation (in particular, the paragraph directly after the numbered list at the top of the page). However, I will exploit the 'usually' as a justification to go off the standard path.

The attack plan has changed a little; I will now simply use the template  with appropriate options, and restricted editing. This will subsequently add some XML tags around the transcluded parts. A custom hook will then be invoked to process the page, removing the tags and applying the desired operations to what is inside them.

//Add this line to the extension core function body $wgHooks['InternalParseBeforeLinks'][] = 'fnPWparseTransclusion';

/* *fnPWparseTransclusion * *Aim: to do recursive matching inside $text for and *Subsequently, to process the stored information, probably using fnPWadjustHeadings */ function fnPWparseTransclusion( &$parser, &$text ){ $reg = '# (?P .*?)>(?P (?((R))(?<=0).|(.*?(?R).*?|.*?))) #s'; }

This rather empty function statement will be expanded further. For now, I will spend some time verifying that this regexp string actually catches what I want (all  section  at deepest level (no occurrence of this thing in 'section')).