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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- 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
