Difference between revisions of "Extension:ParseAfter"
(similar problem) |
m (→Another similar example) |
||
Line 18: | Line 18: | ||
== Another similar example == | == Another similar example == | ||
The following is a similar example, but instead of DPL with %NAME% variables it is this time a $1 that needs to be expanded by the ''#regex'' parser function before pluralisation occurs. | The following is a similar example, but instead of DPL with %NAME% variables it is this time a $1 that needs to be expanded by the ''#regex'' parser function before pluralisation occurs. | ||
+ | {{code|<pre> | ||
{{#regex:{{{1}}}|/(\w+)/|{{plural|$1}}}} | {{#regex:{{{1}}}|/(\w+)/|{{plural|$1}}}} | ||
</pre>}} | </pre>}} | ||
[[Category:Extensions|ParseAfter]] | [[Category:Extensions|ParseAfter]] |
Revision as of 02:12, 4 August 2009
This extension was created in response to some problems that have required inner expressions within brace structures to be parsed after the outer expressions. For example, consider the following wikitext:
The purpose of this is to create a list of all the record types in plural form so that a "Person" record gives a link to "Category:People". The problem is though that at the time Template:Plural is expanded, the parameter it receives (%TITLE%) is not expanded by DPL and therefore results in all pluralisation being the default operation of having an "s" appended.
The solution is to allow some parts of the expression to be parsed after the first parse is done, for example:
After the first parse, the DPL query will expand out to a number of {{#after}} expressions with resolved %TITLE% parts, these then need to be parsed separately. This is slightly tricky because each #after section needs to protect its contents from the wiki parse, yet keep the DPL variables intact so that they can be expanded properly.
Using tags fails
The first idea was to create a tag function which allowed its content to contain brace expressions which it would expand, but this fails because the content of the tag is protected from the parser so that the DPL variables are hidden and not expanded.
Another similar example
The following is a similar example, but instead of DPL with %NAME% variables it is this time a $1 that needs to be expanded by the #regex parser function before pluralisation occurs.