Export Plugins

From MSpace

What Are Export Plugins?

Export plugins are used to present the metadata available in a slicegetitems server request in ways that were not originally intended. Core plugins include the ability to export to xml, csv and plain text but custom plugins can be written on a per site basis to add value to different data sets and scenarios

NB: Export uses XSLT to transform the server XML and as such can only export to plain text file formats - not binary!

Plugin Architecture

Each plugin is a self contained folder which must contain two files:

1. plugin.php
2. plugin.xslt

plugin.php

This is the configuration file for the export plugin

Example config file (for plain text export):

<?php
	$plugin = array();
	$plugin['id']		= 'TXT';
	$plugin['header'] 	= "text/plain";
	$plugin['stripXML']	= true;
?>

• id - the 3 character unique ID for this plugin (used as the file extension in the export script)
• header - the HTTP header that the exported data should be sent with
• stripXML - should the XML declaration added by the XSLT transformation be removed before output

plugin.xslt

This is the XSLT template that is used to transform the output from the mSpace Server into the desired output format. The server output will be a slicegetitems request and as such the export plugin's have access to MetaDataConnections aswell as DirectConnections metadata.

Example template file (for plain text export):

<?xml version="1.0" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text" />
	<xsl:template match="/">
		<xsl:for-each select="//MetadataConnections/ColumnMetadata/RowItem">
			<xsl:value-of select="../@label" />
			<xsl:text>: </xsl:text>
			<xsl:value-of select="@label" />
			<xsl:text>&#10;</xsl:text>
		</xsl:for-each>
	</xsl:template>
</xsl:stylesheet>

Core Plugins

The core mSpace export plugins can be found at:

/export/plugins

Site Specific Plugins

Site specific plugins can be found at:

/sites/{$current_site}/export/plugins

The core plugins are always loaded first so it is possible for a site specific plugin to be loaded with the same unique 3 character ID that will overwrite a core export plugin. This will result in the site specific plugin being used instead of the stock alternative.