In a nutshell this interface provides an export view for Entities, Metadata, Annotations and relationships which can provide a convenient way of accessing data objects in a machine readable form.

Endpoints

The export url is constructed in different ways for entities, relationships and metadata.

All endpoints begin with:

http://yoursite.com/export/[VIEW]/

Where [VIEW] is the format you want the data exported in – e.g. json, opendd, php or default.

Entities
To export a GUID simply add it to the end:

http://yoursite.com/export/[VIEW]/[GUID]/

Annotations & Metadata

Metadata and annotation can be exported by providing the type (‘annotation’ or ‘metadata’) and the appropriate ID.

http://yoursite.com/export/[VIEW]/[GUID]/[annotation|metadata]/[annotation_id|metadata_id]/

Relationships
Follows the same format as above, but with [GUID] being the first guid in the relationship – in essence the entity to which the relationship “belongs”.

http://yoursite.com/export/[VIEW]/[GUID]/relationship/[relationship_id]/

Security

Some items of data (for example user passwords) are restricted from this export view. Exactly what is output by an output view is governed by $object->getExportableValues(); which returns a list of exportable fields in the entity.

In addition, access permissions on the object are respected – meaning that if you can’t see an item in Elgg, you will not be able to see it in the export view either.

I’m going to talk a little bit about how this works. Firstly, Export.

Export works via the views system, and involves creating a brand new view hierarchy for your new format.

We first need to create a plugin, and in this plugin we create a “views” directory. We need to then create a new directory for your format, and then create a couple of views underneath.

The image to the left shows the necessary file hierarchy that you need to create – in this instance to export “myformat”.

Create a directory called “export”. In this directory place the three php files – entity.php, metadata.php and relationship.php – which handle entities, metadata (and annotations) and relationships respectively.

Each of these files are passed objects via $vars. Depending on which file you are in, this might be $vars['entity'], $vars['metadata'] or $vars['relationship'].

It is then up to you to encode and output the object according to your format.

All that remains is to provide the pageshell which handles how the overall page is displayed. This file may set the content-type header or provide wrapping tags (e.g. for XML output).

pageshell.php is passed $vars['body'] containing the output of your other files.

Providing a handler to deal with importing data is also fairly simple, and works through the action interface.

In your plugin’s init function register the action “import/YOURFORMAT”, and point it to your actions/import/myformat.php, e.g.

<?php

	function myformatplugin_init()
	{
		global $CONFIG;

		// Register import action
		register_action('import/myformat', false,
		  $CONFIG->pluginspath . "myformatplugin_init/actions/import/myformat.php");
	}

	// Initialise
	register_elgg_event_handler('init','system','myformatplugin_init');
?>

This will then register an import action which will be picked up by the administrator import export utility. Your action can access the information it needs to import with the call:

$data = get_input('data');

Elgg 1.0 will ship with native support for OpenDD (both import and export) which will allow administrators to migrate between Elgg classic and the new codebase with a minimum amount of effort.

Elgg 1.0 also offers export views in JSON and PHP native, making it easier to reference the data directly and create mashups.

Over time we will be adding more import and export functionality, and I hope you will be too!