Re: Poem extension revealing faults

Thanks, Markus.  I'm glad to know I was dumb for not being able to
figure out a way to do that.  I think the way around it in my case
involves using __NOFACTBOX__ and then making a query to extract the
semantic data from the transcluded pages.  I appreciate you looking
into this.

-Robert

On Mon, May 19, 2008 at 6:16 AM, Markus Krötzsch
<mak <at> aifb.uni-karlsruhe.de> wrote:
> On Freitag, 16. Mai 2008, Robert Murphy wrote:
>> Dear Developers,
>>
>> I have successfully installed the Poem extension
>> (http://www.mediawiki.org/wiki/Extension_talk:Poem) on my wiki and it
>> has been running fine.  However, I just discovered too faults with it,
>> that I now think may be due to Semantic MediaWiki.
>>
>> First, on the talk pages of custom namespaces, use of the <poem> tag
>> makes the error
>> UNIQ583c33685170dbcd-poem-00000000-QINU
>> (for an example, see
>> http://reformedword.org/index.php?title=Greek_talk:Genesis/13&oldid=423322)
>>.
>>
>> Second, it makes the factbox right after the </poem>, in the middle of
>> the page, and the values aren't on the page's main factbox, at the
>> bottom. (see http://reformedword.org/Greek:Psalm/119).
>>
>> While I know some PHP, I don't know the mediawiki framework well
>> enough to know why either of these might be. I posed this question on
>> the extension's page on mediawiki.org and got no reply.  I wrote on
>> the talk page of Poem's creator
>> (http://en.wikipedia.org/wiki/User:Nikola_Smolenski) and he suggested
>> I contact Steve Sanberg (http://en.wikipedia.org/wiki/User:Sanbeg).
>> His reply was:
>>
>>     The UNIQ.. problem seems to be unrelated to the poem extension.
>> Basically, the preprocessor hides XML-style tags with strings like
>> that to prevent them from being treated as wikitext, then unhides them
>> later on; something in the state of your parser must be getting messed
>> up. I looked at your wiki, and I get the same result with poem, cite
>> and nowiki. It's probably best to try disabling some extensions to see
>> which one is causing that. I'm not sure about semantic mediawiki; I'd
>> guess that it's using the wrong hook to detect when the page is ends,
>> so the recursive parse triggers the fact box. That sounds like a bug
>> in semantic mediawiki. -Steve Sanbeg (talk) 15:23, 15 May 2008 (UTC)
>>
>> I've disabled Cite to no avail.  Now I can accept that the talk_page
>> problem might be mine alone, but the factboxes (pl.) in the middle of
>> the pages seems like a SMW error.
>
> The whole thing is due to the way MediaWiki works, and one cannot really blame
> either SMW or Poem here. MediaWiki replaces certain parts of input text with
> that "UNIQ..." stuff. This happens *before* any extension gets to see the
> code -- i.e. extensions do not know what was there before (at least I do not
> know how, and in any case it this stuff usually cannot be understood as
> normal wiki text). Not only poem, but also <!--...-->, <math>, and <nowiki>
> are examples for that. See also bug 13011
> <https://bugzilla.wikimedia.org/show_bug.cgi?id=13011>
>
> One way to improve the situation might be to have a parser function
> {{#poem:... instead of a parser hook <poem> (similar to our #ask that
> replaced <ask>). It is really the way in which MW processes <parserhooks>
> that creates problems here. Parser functions return not UNIQ... but normal
> wiki code, and that would be workable input for SMW.
>
> The other stuff (Factbox in page) happens for other reasons. The problem is
> that SMW uses MW hooks during parsing, i.e. functions that the parser
> triggers when parsing wiki articles. Unfortunately, MediaWiki uses more than
> one parser, and any hook in the parser code is used by all of those. Thus,
> whenever MediaWiki uses a second parser for some part of text, SMW will do
> the same as if this text was the only input. I know of no way of detecting
> whether SMW runs in a subparser or in the "real" parser. Normally, however,
> subparsers are triggered before or after the main page was parsed, and no
> semantic data is found then -- thus the Factbox is empty and remains hidden.
> You can try __NOFACTBOX__ to not display the Factbox, or you can check
> whether it suffices to avoid semantic annotations in certain environments.
>
> -- Markus
>
> --
> Markus Krötzsch
> Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe
> phone +49 (0)721 608 7362          fax +49 (0)721 608 5998
> mak <at> aifb.uni-karlsruhe.de          www  http://korrekt.org
>

--

-- 
Roses are red,Violets are blue,I'm schizophrenic,and so am I.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel