I am thinking about creating a very simple parser function #parse doing nothing but returning parameter 1 with an "'noparse' => false" option. Is there anything like this (or what could be abused for this) already or is there any reason why this might be a bad idea?
The reason I want to have something like this is, I want to create a template (for template and parser function black-box tests) accepting something like {{((}}#somefunction:a{{!}}b{{!}}c{{))}} as parameter value, showing {{#somefunction|a|b|c}} as output and at the same time calling {{#parse: {{((}}#somefunction:a{{!}}b{{!}}c{{))}} }} so that besides the definition also the result can be shown by the template output.
regards, Daniel
On 29 October 2011 01:01, Daniel Werner DanWeEtz@web.de wrote:
I am thinking about creating a very simple parser function #parse doing nothing but returning parameter 1 with an "'noparse' => false" option. Is there anything like this (or what could be abused for this) already or is there any reason why this might be a bad idea?
The reason I want to have something like this is, I want to create a template (for template and parser function black-box tests) accepting something like {{((}}#somefunction:a{{!}}b{{!}}c{{))}} as parameter value, showing {{#somefunction|a|b|c}} as output and at the same time calling {{#parse: {{((}}#somefunction:a{{!}}b{{!}}c{{))}} }} so that besides the definition also the result can be shown by the template output.
regards, Daniel
So basically a function which double-parses wikitext? There are quite a
few potential gotchas with that: firstly losing the parser state if you don't implement it properly and throwing UNIQ...QINUs everywhere; although that can be avoided. I expect you'd get a lot of double-escaping: {{#parse: [[Foo]] }} is going to come out as ""<a href=" http://wiki.com/wiki/Foo%22%3EFoo%3Ca%3E"" or somesuch, as the double brackets will be expanded to an <a> tag on the first parse, then the tag will be escaped on the second. It would probably be easy to get very deeply nested as well. How would you handle pre-save-transform substitutions like signatures and pipe tricks?
--HM
Daniel Werner wrote:
I am thinking about creating a very simple parser function #parse doing nothing but returning parameter 1 with an "'noparse' => false" option. Is there anything like this (or what could be abused for this) already or is there any reason why this might be a bad idea?
The reason I want to have something like this is, I want to create a template (for template and parser function black-box tests) accepting something like {{((}}#somefunction:a{{!}}b{{!}}c{{))}} as parameter value, showing {{#somefunction|a|b|c}} as output and at the same time calling {{#parse: {{((}}#somefunction:a{{!}}b{{!}}c{{))}} }} so that besides the definition also the result can be shown by the template output.
regards, Daniel
I think that would make more sense as a tag extension (parse doesn't look like a good name, what about <wikidemo>?).
@Happy Melon: I think he wants a funtion which shows both parsed wikitext and the original source.
On 29 October 2011 15:08, Platonides Platonides@gmail.com wrote:
Daniel Werner wrote:
I am thinking about creating a very simple parser function #parse doing nothing but returning parameter 1 with an "'noparse' => false" option. Is there anything like this (or what could be abused for this) already or is there any reason why this might be a bad idea?
The reason I want to have something like this is, I want to create a template (for template and parser function black-box tests) accepting something like {{((}}#somefunction:a{{!}}b{{!}}c{{))}} as parameter value, showing {{#somefunction|a|b|c}} as output and at the same time calling {{#parse: {{((}}#somefunction:a{{!}}b{{!}}c{{))}} }} so that besides the definition also the result can be shown by the template
output.
regards, Daniel
I think that would make more sense as a tag extension (parse doesn't look like a good name, what about <wikidemo>?).
@Happy Melon: I think he wants a funtion which shows both parsed wikitext and the original source.
He intends to *build* such a structure, certainly; but I read the OP as saying he wanted to implement it via a template like {{demonstrate template}} [1] but with (just) the backend handled by a new parser function. I agree that you'd be better off/would avoid many of the problems given above by having a tag extension <wikidemo>{{foo|bar|baz=quok}}</wikidemo> that spat out its contents as a parameter to a customisable system message that read something like ""<code><nowiki>$1</nowiki></code> produces: $1"". If I remember the parse order of tag extensions verses parser function extensions right, that should work pretty much straight out of the box??
--HM
[1] https://en.wikipedia.org/wiki/Template:Demonstrate_template
On 30/10/11 16:47, Happy Melon wrote:
I think that would make more sense as a tag extension (parse doesn't look like a good name, what about <wikidemo>?).
@Happy Melon: I think he wants a funtion which shows both parsed wikitext and the original source.
He intends to *build* such a structure, certainly; but I read the OP as saying he wanted to implement it via a template like {{demonstrate template}} [1] but with (just) the backend handled by a new parser function. I agree that you'd be better off/would avoid many of the problems given above by having a tag extension <wikidemo>{{foo|bar|baz=quok}}</wikidemo> that spat out its contents as a parameter to a customisable system message that read something like ""<code><nowiki>$1</nowiki></code> produces: $1"". If I remember the parse order of tag extensions verses parser function extensions right, that should work pretty much straight out of the box??
--HM
A tag hook spits out html, so he would output the content as literal, then recurse and output it again parsed.
wikitech-l@lists.wikimedia.org