Hi, Dmitriy!
Thanks a lot. I´m doing this conversion from tag to parser function not
only with FileProtocolLinks extension, but also with
SyntaxHighlight_GeSHi, so that I´m able to output semantic properties as
highlighted source code.
I'm almost there! I converted both extensions according to your
suggestions, but now the only problem I have in both of them is how to
omit the "[[propertyname::" and "]]" from the output.
In my previous FileProtocolLinks example, I have in a template
{{#file: [[path: {{{path}}}]] }}
and, in a page which uses this template and has
path=c:\whatever\foo.txt, I get the link to
file:///[[path::c:/whatever/foo]], with caption [[path::c:/whatever/foo]]
instead of
file:///c:/whatever/foo, with caption c:/whatever/foo
If I change my template to {{#file: {{{path}}} }}, ommiting the brackets
and the prefix, everything works perfectly with
FileProtocolLinksExtension, but on my modified version of
SyntaxHighlight_Geshi the source is in a "text" variable and needs the
prefix to be correctly rendered in a textarea of a form, instead of a
textfield.
So, do you know if is that possible to fix this?
Here is my actual renderFileProtocolLink function, I´ve played with
'noparse' and 'isHTML' values, but no changed in the result.
/function renderFileProtocolLink(&$parser, $input, $param2 = '')
{
global $wgParser;
$exploded = explode('|', $input);
$uri = htmlentities($exploded[0], ENT_COMPAT, "UTF-8");
if (!isset($exploded[1]) || empty($exploded[1])) {
// no linktext has been specified ==> use the URI as linktext
$linktext = $uri;
}
else {
$linktext = htmlentities($exploded[1], ENT_COMPAT, "UTF-8");
}
$linkResult = sprintf('<a style="color:green" href="file:///%s">%s</a>',
$uri, $linktext);
// #
# //$linkResult// here is c:\whatever\foo /
/// #
return array($linkResult, 'noparse' => false,'isHTML' => true);
}
/
<file:///%5B%5Bjavadoc::P:/brs/documenta%C3%A7%C3%A3o/Manuais%20BRS/brs_apijava/index.html%5D%5D>[],
Matheus
CNIT escreveu:
28.12.2009 21:27, Matheus Garcia Barbosa de Figueiredo ?????:
Thanks again, Dmitriy!
I've converted the extension code to be a parser function, and now
the semantic property was expanded! But there´s still on issue, now
I´m getting the HTML code corresponding to the link as a string in
the text, instead of having a link in the file.
Eg, I can see the text "*<a
href='c:\whatever\foo.txt'>c:\whatever\foo.txt</a>*" in the page that
uses {{#file:c:\whatever\foo.txt }}. This didn´t happen when the
extension were using tags.
I´m looking at parser.php, but, as it´s a little big, I´d appreciate
any help to try to fix this issue.
I´m posting below my modified version of the FileProtocolLinks extension
/$wgExtensionFunctions[] = 'registerFileProtocolLinks';
$wgHooks['LanguageGetMagic'][] = 'registerFileProtocolLinks_Magic';
function registerFileProtocolLinks() {
global $wgParser;
$wgParser->setFunctionHook('file', 'renderFileProtocolLink');
}
function registerFileProtocolLinks_Magic( &$magicWords, $langCode ) {
$magicWords['file'] = array( 0, 'file' );
return true;
}
function renderFileProtocolLink(&$parser, $input, $param2 = '') {
$exploded = explode('|', $input);
$uri = htmlentities($exploded[0], ENT_COMPAT, "UTF-8");
if (!isset($exploded[1]) || empty($exploded[1])) {
// no linktext has been specified ==> use the URI as linktext
$linktext = $uri;
}
else {
$linktext = htmlentities($exploded[1], ENT_COMPAT, "UTF-8");
}
$*linkTextW*=$*parser*->*recursiveTagParse*( $*linktext *);
return sprintf('<a style="color:green" href="file:///%s">%s</a>',
$uri, $*linkTextW*);
}
/
[],
Matheus/
/
Hi Matheus!
You may try to fix this by some of the following options:
1. Remove or comment the "manual" expansion line:
$parser->recursiveTagsParse(). The inner context should already be
expanded automatically for parser functions (not tags).
2. If you want to preserve the output of your function as html, try to
return not a string, but an array instead:
http://www.mediawiki.org/wiki/Manual:Parser_functions#Controlling_the_parsing_of_output
with 'noparse' and / or 'isHTML' elements.
It may be not necessary to take all steps. First of all, I would try
to remove recursiveTagsParse(). If that wouldn't help, try to
"protect" the output with array (step 2).
The parser of MediaWiki is large and quite complex, there are not many
experts on that. Even SMW originally has some troubles until Daniel
Friesen had patched it. I know only two experts of parser, Tim
Starling (an author and extremly busy man) and Daniel Friesen. If
nothing helps, try to mail Daniel, he was subscribed to this list.
Dmitriy
--
/Matheus Garcia Barbosa de Figueiredo/
/Tel.: (31) 2108 - 7018/
/Analista de Sistemas/
/Gerência de Desenvolvimento de Sistemas - GDS/
/Gerência-Geral de Sistemas de Informação - GSI/
/Assembleia Legislativa de Minas Gerais - ALMG/
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
