Thread view

I´ve created a template which has a property called "path", which is
intended to store a string that represents a path to a file in a network
file system. I´d like to show this property inside <file> and </file>
tags, which are used by the FileProtocolLinks
<http://www.mediawiki.org/wiki/Extension:FileProtocolLinks&gt; extension to
create a link using file protocol.
Unfortunatelly, the semantic property is not "resolved", the link is
incorrectly created to the literal "[[path::{{{path}}}]]", instead of
eg. "c:\whateverdir\foo.txt".
The text in my template is:
<file>[[path::{{{path}}}]]</file>
If I remove the tags the content is show correctly, but I do need to
envolve it in the tags to use the extension.
I´m pretty sure it is not a problem with SMW, but with the
FileProtocolLinks extension, which seems to be processed first than SMW
markup and not parsing it´s contents. I´d like the extension to call the
mediawiki parser on it´s contents, but I don't know how to do it yet.
The same may occur also with another tag based extensions.
The relevant part of this extension is:
function renderFileProtocolLink($input)
{
$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");
}
return sprintf('<a style="color:green" href="file:///%s">%s</a>';,
$uri, *$linktext*);
}
So, do any of you guys cold help me fix this issue? Or at least point me
where could I look for that? I´m doing my first steps in developing SMW
extensions
Thanks,
Matheus
--
/Matheus Garcia Barbosa de Figueiredo/
///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/

23.12.2009 18:38, Matheus Garcia Barbosa de Figueiredo ?????:
> I´ve created a template which has a property called "path", which is
> intended to store a string that represents a path to a file in a
> network file system. I´d like to show this property inside <file> and
> </file> tags, which are used by the FileProtocolLinks
> <http://www.mediawiki.org/wiki/Extension:FileProtocolLinks&gt; extension
> to create a link using file protocol.
>
> Unfortunatelly, the semantic property is not "resolved", the link is
> incorrectly created to the literal "[[path::{{{path}}}]]", instead of
> eg. "c:\whateverdir\foo.txt".
>
> The text in my template is:
> <file>[[path::{{{path}}}]]</file>
>
> If I remove the tags the content is show correctly, but I do need to
> envolve it in the tags to use the extension.
>
> I´m pretty sure it is not a problem with SMW, but with the
> FileProtocolLinks extension, which seems to be processed first than
> SMW markup and not parsing it´s contents. I´d like the extension to
> call the mediawiki parser on it´s contents, but I don't know how to do
> it yet. The same may occur also with another tag based extensions.
> The relevant part of this extension is:
>
> function renderFileProtocolLink($input)
> {
> $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");
> }
>
> return sprintf('<a style="color:green" href="file:///%s">%s</a>';,
> $uri, *$linktext*);
> }
>
> So, do any of you guys cold help me fix this issue? Or at least point
> me where could I look for that? I´m doing my first steps in developing
> SMW extensions
>
Try to use $input = Parser->recursiveTagParse( $input ) The extension
should recieve an instance of Parser object upon the hook call.
Dmitriy

It seems to me that "File" is a good candidate for a new SMW property type,
whether defined in SMW itself or another extension - the display of this
type would be a link to that file, eliminating the need for extensions like
FileProtocolLinks.
Matheus - as you suspected, the fact that FileProtocolLinks uses tags, as
opposed to parser functions, makes it (I think) impossible for
FileProtocolLinks as currently written and SMW to work together.
Since you're talking about developing extensions, this might be a good
opportunity for a new extension that defined a "File" type, maybe called
"Semantic Local Files" (I'd say "Semantic Files", but I'd like the "SF"
acronym to be reserved for Semantic Forms :) ). See the latest version of
the Semantic Maps extension for an example of an extension defining its own
property type, "Geographic coordinate" (the long-term plan, as I understand
it, is to move handling of coordinates completely out of SMW and into
Semantic Maps).
-Yaron
On Thu, Dec 24, 2009 at 10:47 PM, CNIT <cnit@...> wrote:
> 23.12.2009 18:38, Matheus Garcia Barbosa de Figueiredo пишет:
>
> I´ve created a template which has a property called "path", which is
> intended to store a string that represents a path to a file in a network
> file system. I´d like to show this property inside <file> and </file> tags,
> which are used by the FileProtocolLinks<http://www.mediawiki.org/wiki/Extension:FileProtocolLinks>extension to create a link using file protocol.
>
> Unfortunatelly, the semantic property is not "resolved", the link is
> incorrectly created to the literal "[[path::{{{path}}}]]", instead of eg.
> "c:\whateverdir\foo.txt".
>
> The text in my template is:
> <file>[[path::{{{path}}}]]</file>
>
> If I remove the tags the content is show correctly, but I do need to
> envolve it in the tags to use the extension.
>
> I´m pretty sure it is not a problem with SMW, but with the
> FileProtocolLinks extension, which seems to be processed first than SMW
> markup and not parsing it´s contents. I´d like the extension to call the
> mediawiki parser on it´s contents, but I don't know how to do it yet. The
> same may occur also with another tag based extensions.
>
> The relevant part of this extension is:
>
> function renderFileProtocolLink($input){
> $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");
> }
>
> return sprintf('<a style="color:green" href="file:///%s">%s</a>';,
> $uri, *$linktext*);}
>
> So, do any of you guys cold help me fix this issue? Or at least point me
> where could I look for that? I´m doing my first steps in developing SMW
> extensions
>
> Try to use $input = Parser->recursiveTagParse( $input ) The extension
> should recieve an instance of Parser object upon the hook call.
> Dmitriy
>
>
> ------------------------------------------------------------------------------
> 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@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>

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&gt;[],
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/