Writing javascript result printers

This documentation is work in progress; some sections are not finished yet.

This guide applies for result printers compatible with SMW 1.9 and later, and MediaWiki 1.19 and later.

JavaScript result printer (JSRPrinter)
See also Writing result printers

SMWAPI integration
''The parser and formatters for the query descriptions can be quickly implemented in JS making use of a new API module. This ensures completeness and consistency with the PHP implementation, at the cost of some latency. Later on the implementation of these can always be changed without affecting other parts of the system.''
 * Jeroen wrote

Some interfaces


 * smw.AskParser: parse( string, options ) -> parserResult // containing validity, error array and if valid smw.QueryDescription
 * smw.AskFormatter: format( smw.QueryDescription, options ) -> string
 * smw.Store: runQuery( smw.QueryDescription, params ) -> smw.QueryResult // main implementation of this would use the ask API

See SMW and Wikidata

jQuery UI widgets

 * Tips for Developing jQuery UI 1.8 Widgets

Custom events (a.k.a. MediaWiki hooks)
Add a custom event

Add callback to a custom event or

Guidelines for JavaScript resources
Plug-ins that are being used with a printer are normally placed in a folder called  following the individual printer but for common resources that will be used in more than printer the folder   can be used to share plug-ins among other printers.

In light of genuine courtesy for the plug-in developer, please be so kind to add relevant information to the Help:Plug-ins page.

Register a resource
Resources register (see also MW's ResourceLoader) their details in  and once those plug-ins are made available through a unique identifier (such as   etc.), modules are accessible via:
 * , or
 * within JavaScript itself
 * within JavaScript itself

Resource naming
Experience showed that separating the plug-in resource definition from the implemented JavaScript code (the code that uses the plug-in) will help in identifying malicious code fragments and make plug-ins available to others. Some naming convention can help to achieve consistency among registered resources:
 * ext. identifies it as external resource
 * ext.srf. identifies the resource as member of SemanticResultFormats
 * ext.srf. references the resource to a printer
 * ext.srf. . additional namespace
 * ext.jquery. identifies the individual jquery plug-in

SRF plug-in namespace
In order to avoid the "pollution" of the $ namespace with unnecessary invoked methods or functions it is recommended to use the "semanticFormats" namespace for JavaScript related to SRF functions.

An example in how to extend methods into semanticFormats namespace, see examples in. A class references can be added (if appropriate declaration in srf.util* exists) like: var options ={ 'context'  : chart, 'container' : container, 'id'       : chartID, 'info'     : infotext, 'data'     : data };
 * 1) Usage

// Gridview class reference new srf.util.grid( options );

An example on how to add methods to the srf.formats namespace, see the sparkline example which follows a similar pattern like: new srf.formats.sparkline( { context: $( this ) } );

Above examples will amend the namespace window.semanticFormats = window.srf = srf with methods declared in srf.util* or srf.formats.*.

Code quality and testing
jshint is a static code analysis tool which can help identify potential erroneous code and mistakes. Before making a commit, you want to check your JavaScript and correct any potential messages from jshint in order to allow an easier code review process.

For testing related topics, see QUnit tests.