Last modified: 2011-07-22 14:54:04 UTC
I encountered several problems when rendering a Semantic Maps marker using templates. =========================== a) "=" in template parameter values considered harmful =========================== When I tried to render three parameters in a simple template ({{{1}}} {{{2}}} {{{3}}}) it happened that some of the template variables were not replaced by actual parameters (which were actually queried correnctly, as tested by chekching format=table output of the same query). Investigating the problem more deeply it appeared that especially parameters of annotation type URL and Email caused trouble. Looking into SM_MapPrinter.php (method addResultRow()) I found line 246 ($label[] = $object->getLongText( $outputmode, $skin );) being the tricky part. This causes a plain input value "my@mail.xyz" to be transformed in a string "<a href="mailto:my@mail.xyz" class="external " title="mailto:my@mail.xyz">" which is then later ($text = preg_replace( '/\n+/m', '<br />', $wgParser->recursiveTagParse( '{{' . implode( '|', $segments ) . '}}' ) );) parsed as template code. This ultimately fails (i.e. does not bind the value to the template variable) most probably due to the "=" sign (c.f. http://en.wikipedia.org/wiki/Help:Template#URL_problems). A fix for this issue (as indicated in the text just referenced) is to explicitly prefix all template variables with their positon (i.e. "1=myvale"). The following code, inserted just before the line ("$segments = array_merge(") does the job for me: // start $n=0; foreach($label as $l){ $label[$n] = ($n+1) . "=" . $label[$n]; // do explicit template numbering to avoid http://en.wikipedia.org/wiki/Help:Template#URL_problems $n++; } // end =========================== b) Template parameters not available in raw form =========================== A second, related concern is the fact that passing result values in a "rendered" style (e.g. "<a href="mailto:my@mail.xyz" class="external " title="mailto:my@mail.xyz">" instead of "my@mail.xyz") reduces flexibility in template design since the "raw" data can not be used. Therefore I changed $label[] = $object->getLongText( $outputmode, $skin ); to $label[] = $object->getWikiValue(); While this seems to work in the first, I can not rule out probable side-effects of this completely (due to lack of overview about the general code). The same issue applies to the title as well: * if ( $this->template ) $titleForTemplate = $object->getLongText( $outputmode, NULL ); * vs. if ( $this->template ) $titleForTemplate = $object->getWikiValue(); NOTE: although changes suggested in b) seem to resolve a) at a first glance, this is not completely true - especially if you have URLs with "=" as raw data ("http://www.myweb.com/index.php?var=1" -> will break while "1=http://www.myweb.com/index.php?var=1" works). My system setup is: MediaWiki 1.15.4 PHP 5.2.11-pl0-udmedia (apache) MySQL 5.0.83-log Maps (Version 0.6.5) (recent SVN head) Semantic MediaWiki (Version 1.5.1.1) Semantic Maps (Version 0.6.5 rc1) (plus various other extensions)
Thanks for bringing this issue and the one described in bug 24556 to my attention. These things used to work properly at some point in the past, so must somehow have broken. I will look into this when I have time, but that can take a while. Feel free to poke at it yourself and send a patch when fixing it though :)
Sure I can prepare a patch. However, it would be great if you could give me some rough input regarding certain design decisions: 1) Backwards compability: changes proposed in part b) will create a slighly different behaviour and might break templates in use based on the current implementation. Is this OK? (Besides that, Bug 24556 needs to be resolved before doing so). 2) Side-effects: based on the code of SM_MapPrinter.php, I can not see many possible side-effects when modifying $this->locations['text'] for template mode. Do you agree on that, or is there anything else I should be aware of (I am used to MW extension development, but I did not yet dig deep into Maps/SemanticMaps except of for the issue described here). 3) Genericity: Without thinking too much about it I guess there might be further cases (special chars in page titles etc.) which might break the template rendering. Were there any past considerations of such issues and what is the philosophy you recommend for implementation (try to catch/avoid as many cases in the code vs. telling people how to avoid certain issues in the docs)? 4) Reuse: You said things used to work properly in the past. Could it be worthwhile to investigate/re-adapt the past solution? Do you have any kind of pointer (time/incident) regarding this?
This should have been fixed quite a while ago :)