Markus,
> Hence it
> seems to be impossible to generally switch #ask to return full HTML,
> even if
> it can be done for parser functions in MediaWiki.
Suspected as much.
> What we do in such cases (timeline is a good example) is to encode
> all data in
> admissible HTML elements (span, div, css-classes) and then register a
> Javascript that transforms this HTML into the real HTML we would
> like to have
> there. Any result printer can cause arbitrary JavaScript and CSS to
> be loaded
> for the given page, using smwfRequireHeadItem as documented in
> SMW_GlobalFunctions.php. But I see that this method would require
> quite some
> changes to your code.
Actually, this works like a charm! I hadn't quite figured out what
smwfRequireHeadItem was for, this explains it. Thankfully, this is
exactly how OpenLayers works--you put a simple <div> in the page, and
then add a bunch of Javascript to manipulate that div. The code change
was actually trivial, as it turns out.
This brings me to, I figure, about 75-80% done with the transition.
Maybe I'll have it done by Wednesday after all!
Thanks for saving the day once again!
-Matt
On Mar 17, 2008, at 4:04 AM, Markus Krötzsch wrote:
> The issue here is that #ask returns wiki text on purpose, so that
> one might
> also use wiki-text based templates for #ask output. For example you
> can
> format #ask with a template (format=template) that includes piped
> table
> syntax for wiki tables. The table header can still be written in
> front of the
> #ask statement, i.e. something like
>
> {|
> {{#ask: ...}}
> |}
>
> Clearly, #ask could not parse its content to HTML (without the table
> header,
> the wiki table syntax would not be recognised by the MW parser).
> Hence it
> seems to be impossible to generally switch #ask to return full HTML,
> even if
> it can be done for parser functions in MediaWiki.
>
> What we do in such cases (timeline is a good example) is to encode
> all data in
> admissible HTML elements (span, div, css-classes) and then register a
> Javascript that transforms this HTML into the real HTML we would
> like to have
> there. Any result printer can cause arbitrary JavaScript and CSS to
> be loaded
> for the given page, using smwfRequireHeadItem as documented in
> SMW_GlobalFunctions.php. But I see that this method would require
> quite some
> changes to your code. I think even <ask> cannot include arbitrary HTML
> without it being escaped later on, and in any case <ask> cannot
> provide the
> close interface to other page contents as #ask does (e.g. <ask> does
> not even
> support the use of template parameters within the query, whereas
> #ask admits
> query string to be built by parameterised templates and much more).
>
> Another work-around you might take is to have a second parser function
> (say "#maptohtml") that returns HTML for your maps, and then have
> your result
> printer generate input code for that parser function. Of course this
> must be
> done in a save way since anyone could use #maptohtml directly. But
> it might
> be possible to do that in an efficient way, e.g. if only your custom
> javascript remains to be inserted after generating the basic HTML
> structure.
>
> Good luck ...
>
> Markus
>
>
> On Montag, 17. März 2008, Matt Williamson wrote:
>> Nope, <nowiki> didn't work...looks like it's being run through the
>> same parser/sanitizer that regular wiki text goes through...so if
>> that
>> had worked, they'd have big XSS problems, so that's good I guess...
>>
>> BTW, only the parser function does this...the tag hook works fine! I
>> expected as much, though--the tag extensions have to return HTML vs.
>> wikitext.
>>
>> Also, I tried the following: I changed my own extension's
>> {{#slmap: }}
>> parser function to be a near-exact clone of the
>> smwfProcessInlineQueryParserFunction , except I changed the first
>> return line, such that the function looks like this:
>>
>> function slfMapParserFunction(&$parser) {
>> global $smwgQEnabled, $smwgIP, $smwgIQRunningNumber;
>> if ($smwgQEnabled) {
>> $smwgIQRunningNumber++;
>> require_once($smwgIP . '/includes/SMW_QueryProcessor.php');
>> $params = func_get_args();
>> array_shift( $params ); // we already know the $parser ...
>> return array(0 =>
>> SMWQueryProcessor
>>
>> ::getResultFromFunctionParams($params,SMW_OUTPUT_WIKI), 'noparse' =>
>>
>> true, 'isHTML' => true);
>> } else {
>> return
>> smwfEncodeMessages(array(wfMsgForContent('smw_iq_disabled')));
>> }
>> }
>>
>> Incidentally, trying to pass SMW_OUTPUT_HTML as the $outputformat
>> parameter didn't help, but I figured that would be the case. I also
>> tried returning the necessary array-wrapped result direct from my
>> ResultPrinter's getResultText() function, and that didn't work either
>> (it would have broken the tag hook version anyway).
>>
>> Obviously, changing smwfProcessInlineQueryParserFunction in this way
>> would break several things, at least unless you also changed the
>> SMW_OUTPUT_WIKI to SMW_OUTPUT_HTML...which I'm guessing wouldn't be
>> near as efficient as the current implementation. So, one possible
>> solution I see would be to have the SMW
>> smwfProcessInlineQueryParserFunction function somehow introspect the
>> ResultPrinter object being used to determine whether it wants to be
>> returned to the MW parser as wikitext or HTML. But that might be non-
>> trivial. Even better, I'd still love to hear another way to work
>> around this! :-)
>>
>> Ideally I suppose my ResultPrinter class should be able to see the
>> outputformat parameter and either return wikitext or HTML
>> accordingly...but I can't really do what I'm trying to do with
>> wikitext...
>>
>> -Matt
>>
>> On Mar 16, 2008, at 7:12 PM, S Page wrote:
>>> Matt Williamson wrote:
>>>> I wrote a class that subclasses SMWResultPrinter, and it works,
>>>> except that when it returns its output, it's translating HTML tags
>>>> into < and >--at least partially.
>>>
>>> Surround your output with <nowiki> ... </nowiki> tags?
>>> Use the HTML entities < and > for < and > ?
>>>
>>> Guessing away,
>>> --
>>> =S Page
>>
>> -------------------------------------------------------------------------
>> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
>
> --
> Markus Krötzsch
> Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe
> phone +49 (0)721 608 7362 fax +49 (0)721 608 5998
> [EMAIL PROTECTED] www http://korrekt.org
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
