I've spent a bit of time trying to figure out how to replace the flawed "{{fullurl:" with a ParserFunction "{{#fullurl:" that would correctly encode its parameters, while keeping in mind a more formal wikimarkup language definition implemented by recursive descent.
In trying to understand the abtruse calling sequence for the ParserFunctions, one of the definitional difficulties is that the parameters are expanded (using call_user_func_array). The currently defined ParserFunctions all have fixed positional parameters.
Unfortunately, fullurl/localurl/whateverurl should have a variable number of parameters. Future functions might also have a variable number of parameters, or possibly named parameters with defaults.
The current handling doesn't seem very amenable to formal language definition or future mixing of a compiled parser with calls to external PHP functions.
Is my reading of the code correct?
Is is possible to redefine ParserFunctions to pass variable parameters and let each function process them?
On 17/05/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
I've spent a bit of time trying to figure out how to replace the flawed "{{fullurl:" with a ParserFunction "{{#fullurl:" that would correctly encode its parameters, while keeping in mind a more formal wikimarkup language definition implemented by recursive descent.
Don't replace built-ins with extensions. Fix the existing problem. :)
Rob Church
Rob Church wrote:
On 17/05/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
I've spent a bit of time trying to figure out how to replace the flawed "{{fullurl:" with a ParserFunction "{{#fullurl:" that would correctly encode its parameters, while keeping in mind a more formal wikimarkup language definition implemented by recursive descent.
Don't replace built-ins with extensions. Fix the existing problem. :)
I'm concerned with backward compatibility, and future extensibility.
There are quite a few instances of both "{{fullurl:" and "{{localurl:", and it will be bloody hard to find and fix them all on a flag day. My thought is that it might easier to change to the new "{{#...:" syntax, allowing gradual migration.
Admittedly, this assumes that there was a reason for the parameters not being encoded. I'd asked whether this was deliberate, and got no answer, in the "odd behaviour of {fullurl:...}" thread. Nobody can remember?
Also, the current "{{fullurl:" and "{{localurl:", are extremely wikipedia specific, following different conventions from the standard encode(), rawencode(), encodeURL(), urlencode(), rawurlencode() functions (to cite a few different languages). That might not be desirable for all future wiki.
Finally, there is an attempt to move in the direction of standard syntax, getting away from "Magic Word" reserved template names to generalized functions and configurable language internationalization. Unless I'm completely misinterpreting earlier messages?
William Allen Simpson-2 wrote:
Is is possible to redefine ParserFunctions to pass variable parameters and let each function process them?
Yes.
Go here and look at how #switch is implemented: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ParserFunctions/P...
HTH HAND
wikitech-l@lists.wikimedia.org