Developer Area/Import//Export/LEAP Export: Difference between revisions
From Mahara Wiki
< Developer Area | Import//Export
Brettwilkins (talk | contribs) (Created page with "Mahara's Leap export is implemented as a plugin for Mahara's "Export" plugin type. It allows Mahara to export [http://wiki.cetis.ac.u…") |
No edit summary |
||
Line 5: | Line 5: | ||
<div id="section_1"> | <div id="section_1"> | ||
=== Architecture === | ===Architecture=== | ||
The Leap export plugin lives in <code>htdocs/export/leap/</code>. The core export algorithm is implemented here, as well as other parts necessary to implement the Mahara export API. Most of the work is done by the <code>PluginExportLeap</code> class, which represents the process of producing an export for an individual user. | The Leap export plugin lives in <code>htdocs/export/leap/</code>. The core export algorithm is implemented here, as well as other parts necessary to implement the Mahara export API. Most of the work is done by the <code>PluginExportLeap</code> class, which represents the process of producing an export for an individual user. | ||
Line 13: | Line 13: | ||
</div><div id="section_2"> | </div><div id="section_2"> | ||
=== Implementation === | ===Implementation=== | ||
The export is generated by building a string containing the Leap2A XML, as well as copying files from their location in dataroot into a temporary directory. The XML is written to a leap2a.xml file, and the entire package is zipped up. The plugin provides the location of the zip file to caller. | The export is generated by building a string containing the Leap2A XML, as well as copying files from their location in dataroot into a temporary directory. The XML is written to a leap2a.xml file, and the entire package is zipped up. The plugin provides the location of the zip file to caller. | ||
Line 21: | Line 21: | ||
<div id="section_3"> | <div id="section_3"> | ||
==== Artefacts ==== | ====Artefacts==== | ||
Artefact plugins have two choices for implementing Leap2A export - either to generate XML for each artefact in turn, or generate XML all in one go for all of their artefacts. | Artefact plugins have two choices for implementing Leap2A export - either to generate XML for each artefact in turn, or generate XML all in one go for all of their artefacts. | ||
Line 36: | Line 36: | ||
</div><div id="section_4"> | </div><div id="section_4"> | ||
==== Views ==== | ====Views==== | ||
The plugin exports views itself as selections of the type 'Webpage'. | The plugin exports views itself as selections of the type 'Webpage'. | ||
Line 42: | Line 42: | ||
</div></div><div id="section_5"> | </div></div><div id="section_5"> | ||
=== Exporting from Other Systems === | ===Exporting from Other Systems=== | ||
We have documented the results of exporting to other systems, as well as importing, in the [[../../../../Developer Area/Import//Export/Interoperability|Interoperability]] section. | We have documented the results of exporting to other systems, as well as importing, in the [[../../../../Developer Area/Import//Export/Interoperability|Interoperability]] section. |
Revision as of 16:15, 11 Mayıs 2011
Mahara's Leap export is implemented as a plugin for Mahara's "Export" plugin type. It allows Mahara to export Leap2A files, which Mahara can also import.
Note:'' A working understanding of the Leap2A spec will help you understand the documentation written here. We suggest you at least partially familiarise yourself with the spec before diving into the code or this documentation.
Architecture
The Leap export plugin lives in htdocs/export/leap/
. The core export algorithm is implemented here, as well as other parts necessary to implement the Mahara export API. Most of the work is done by the PluginExportLeap
class, which represents the process of producing an export for an individual user.
In addition to this, each artefact plugin can provide the export/leap/lib.php
file, which the plugin searches for in order to do most of the heavy lifting. The core Mahara artefact plugins all provide the ability to export their respective artefact types. If you are writing an artefact plugin and your plugin does not supply any artefact type that can be meaningly exported in a Leap file, you don't have to provide the export/leap/
directory at all.
Implementation
The export is generated by building a string containing the Leap2A XML, as well as copying files from their location in dataroot into a temporary directory. The XML is written to a leap2a.xml file, and the entire package is zipped up. The plugin provides the location of the zip file to caller.
Mostly, the XML is built by use of smarty templates.
Artefacts
Artefact plugins have two choices for implementing Leap2A export - either to generate XML for each artefact in turn, or generate XML all in one go for all of their artefacts.
If using the former method, there is a base class - LeapExportElement - provided to give rudimentary export of any artefact. The artefact plugin may have to extend this class to add extra information to the exported XML for artefacts of a given type. If this is the case, the artefact plugin can provide a LeapExportElement
class (e.g. LeapExportElementBlog
), which the plugin will automatically use when found.
If using the latter method, the artefact plugin needs to provide a LeapExport
class that extends LeapExportArtefactPlugin
. This class has one contract method - get_export_xml
. It is then up to that method to generate all the XML for all artefacts in the plugin. The internal artefact plugin does this to generate the persondata element for the user who is exporting the portfolio.
Views
The plugin exports views itself as selections of the type 'Webpage'.
Exporting from Other Systems
We have documented the results of exporting to other systems, as well as importing, in the Interoperability section.