Well, at least from a performance viewpoint, it makes sense to do #set and
#display in one parse if possible. I do not want to contribute to the general
interface discussion here, but I can offer a workaround for those who would
like to have a #"set+display" right now. Insert the code below this email into
your LocalSettings.php, and you will obtain a function #Property that works
like [[::]]. Example: {{#Property:has capital|Berlin}}.The below code requires a recent MediaWiki (or otherwise the parser function registration must be changed, see SMW's SMW_GlobalSettings.php for code that works on older versions, too). You should also use SMW from SVN, since some issues with string-escaping have required fixes to make #Property fully work with Type:Code. Another advantage of #Property is that it allows for extremely long property values without crashing PHP (a known issue with the regular expression library used for [[::]]). For an example, see [1]. Cheers, Markus [1] http://km.aifb.uni- karlsruhe.de/projects/owltests/index.php/TestCase:WebOnt-description-logic-661 ### Code for LocalSettings.php: $wgHooks['ParserFirstCallInit'][] = 'addPropertyParserFunction'; $wgHooks['LanguageGetMagic'][] = 'addPropertyMagicWord'; function addPropertyMagicWord(&$magicWords, $langCode) { $magicWords['property'] = array( 0, 'Property' ); return true; } function addPropertyParserFunction(&$parser) { $parser->setFunctionHook( 'property', 'doPropertyParserFunction' ); return true; } function doPropertyParserFunction(&$parser) { global $smwgInlineErrors; $storeannotations = smwfIsSemanticsProcessed($parser->getTitle()- >getNamespace()); $params = func_get_args(); array_shift( $params ); // we already know the $parser ... if (array_key_exists(0,$params)) { $property = $params[0]; } else { $property = ''; } if (array_key_exists(1,$params)) { $value = $params[1]; } else { $value = ''; } $dv = SMWParseData::addProperty($property, $value, false, $parser, $storeannotations); $result = $dv->getShortWikitext(true); if ( ($smwgInlineErrors && $storeannotations) && (!$dv->isValid()) ) { $result .= $dv->getErrorText(); } return $result; } ### End code for LocalSettings.php: On Montag, 12. Januar 2009, Daniel Friesen wrote: > Not if you put the display and the #set calls next to each other. > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) > ~Profile/Portfolio: http://nadir-seen-fire.com > -The Nadir-Point Group (http://nadir-point.com) > --It's Wiki-Tools subgroup (http://wiki-tools.com) > --The ElectronicMe project (http://electronic-me.org) > -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) > --Animepedia (http://anime.wikia.com) > --Narutopedia (http://naruto.wikia.com) > > Yaron Koren wrote: > > Well, it just means more work for the administrator if you have separate > > display and annotation. In the worst case, if the value is a > > comma-separated list then you would need to have two #arraymap (or > > #arraymaptemplate) calls to handle it. > > -Yaron > > > > On Fri, Jan 9, 2009 at 9:03 PM, Daniel Friesen <[email protected]>wrote: > >> Why should it ever display on the screen? #set and #declare were meant > >> for being able to set properties in templates without the issues caused > >> by the link notation. I can't think of a single case where I would want > >> #set or #declare to display, it's all input being handled so the data > >> should be easy to display and annotate separately. > >> > >> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) > >> ~Profile/Portfolio: http://nadir-seen-fire.com > >> -The Nadir-Point Group (http://nadir-point.com) > >> --It's Wiki-Tools subgroup (http://wiki-tools.com) > >> --The ElectronicMe project (http://electronic-me.org) > >> -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) > >> --Animepedia (http://anime.wikia.com) > >> --Narutopedia (http://naruto.wikia.com) > >> > >> Yaron Koren wrote: > >>> Hi, > >>> It's come up repeatedly that the double-bracket calls that SMW uses to > >>> define semantic data cause problems due to MediaWiki's parsing order: > >> > >> most > >> > >>> notably, single- and double-brackets within such calls usually cause > >>> the data to not get defined at all. An obvious solution is to use, > >>> instead of double brackets (convenient as they are), parser functions, > >>> which are handled very well. But in fact a parser function already > >>> exists that does this: #set, which was added to SMW a few months ago; > >>> it is called in this format: > >>> > >>> {{#set:property-name=value}} > >>> > >>> The only downside of #set is that it's "silent", meaning that it > >>> doesn't display the data on the screen; it just stores it. Why not > >>> change #set so that it does display the value? Or better yet, add > >>> another parameter to allow for setting of silent or non-silent. I would > >>> argue to make the > >> > >> default > >> > >>> be non-silent, so that a regular call would look like: > >>> > >>> {{#set:property-name=value}} > >>> > >>> while a silent call might look like: > >>> > >>> {{#set:property-name=value|hide}} > >>> > >>> (You could do it the either way for backward compatibility, though I > >> > >> don't > >> > >>> think that's a big issue since I don't know if anyone's using it at the > >>> moment.) > >>> > >>> This way, people could have the option of an alternate approach in > >>> cases where the double-bracket approach doesn't work. > >>> > >>> -Yaron > >>> > >>> > >>> ----------------------------------------------------------------------- > >>>- > >> > >> ------------------------------------------------------------------------ > >>------ > >> > >>> Check out the new SourceForge.net Marketplace. > >>> It is the best place to buy or sell services for > >>> just about anything Open Source. > >>> http://p.sf.net/sfu/Xq1LFB > >>> ----------------------------------------------------------------------- > >>>- > >>> > >>> _______________________________________________ > >>> Semediawiki-devel mailing list > >>> [email protected] > >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > >> > >> ------------------------------------------------------------------------ > >>------ Check out the new SourceForge.net Marketplace. > >> It is the best place to buy or sell services for > >> just about anything Open Source. > >> http://p.sf.net/sfu/Xq1LFB > >> _______________________________________________ > >> Semediawiki-devel mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------- > >----- Check out the new SourceForge.net Marketplace. > > It is the best place to buy or sell services for > > just about anything Open Source. > > http://p.sf.net/sfu/Xq1LFB > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Semediawiki-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > --------------------------------------------------------------------------- >--- Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > Semediawiki-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Markus Krötzsch Semantic MediaWiki http://semantic-mediawiki.org http://korrekt.org [email protected]
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB
_______________________________________________ Semediawiki-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
