Version 8 (modified by Dominic König, 12 years ago) ( diff )


S3XRC - S3Resource


Resources are dynamic, document-alike representations of data objects on the Eden server. As such, they can represent both single instances as well as structured sets of data objects.

Note: in the database context, a single instance of a data object is typically called a record (or row), with fields (or columns) as its atomic elements. However, even though S3Resources are typically bound to a relational database and therefore the record/field terminology is often used in this regard, they are not intended to provide any object-relational mapping (ORM).

S3Resources implement an extensible, multi-format RESTful API to retrieve and manipulate data on the Eden server by HTTP requests, where every resource can be addressed by an individual URL.

In the context of the Model-View-Controller (MVC) architecture, S3Resources are controller-generated objects. Typically, the controller generates a resource in response to an incoming HTTP request and returns a view of it (output) to the client:

To parse the URL and the incoming HTTP request and to generate a corresponding resource, the controller can make use of the S3Request helper class.


A S3Resource consists of elements which can be either resources themselves (container type) or data (atomic types).

Container type elements within a resource can be:

  • primary resources (independent data objects)
  • component resources (objects which are part of a primary object)
  • referenced resources (objects which are referenced by primary or component resources)


This interface is used by the s3_rest_controller() function:

res, req = s3xrc.parse_request(module, resource)
output = res.execute_request(req, **attr)

where res is the S3Resource instance, and req the S3Request instance.

Flow Diagram

Passing information between main Controller & Prep

Scope normally means that these 2 sections can only talk to each other via globals or the Request object.

If you need to pass data between them, you can use this trick:

vars = {} # the surrounding dict
def prep(r, vars):
    vars.update(x=y) # the actual variable to pass is x
    return True

response.s3.prep = lambda r, vars=vars: prep(r, vars)

output = shn_rest_controller(module, resource)

x = vars.get(x, None)

An example usage is in controllers/ for location()

Export behavior

The XML export function supports HTTP/GET. If no record ID is specified in the request, this will get a list attempt, otherwise a read attempt to the specified record. This is the same as for the Joined Resource Controller in general, except the following behaviour:

  • when attempting to read a joined resource, you will get both the primary record and all belonging records in this joined resource.
  • when attempting to read a primary resource, you will get both the primary record and all belonging records in all joined resources.

Import behavior

The XML import function supports HTTP/PUT, HTTP/POST as well as HTTP/GET with explicit create and update.

However, the use of POST is actually wrong here and is therefore handled like GET. The only way for list+create with ExtJS, though.

The behaviour is similar to the XML Export function:

  • when there is no join in the request, resources will be joined automatically:
    • the resource-element of the primary will be imported
    • when joined resources for that element are also found in the XML source, they will be imported as well (all)
  • when a joined resource is specified in the request, only elements for that joined resource will be imported - no other joined resources and not the primary record either

The import function can read from the request body (by default), but also pull from files or URL's:

  • to import XML data from files, append a ?filename=<full_path_to_xml_file> variable to the request URL.
  • to fetch XML data from URL's, append a ?fetchurl=<fully_qualified_url> variable to the request URL. Sources can be HTTP as well as FTP sources, as long as they export XML data.

This allows you to transfer resources directly from one Sahana Eden server to the other, e.g.:


fetches all person data (including all joined resources) from and creates or updates corresponding records on localhost.


Imported data is validated using the requires validators as specified in the models, before comitting them to the database.

In case of any validation error, no data import will happen at all. Instead, the import data tree with error attributes added to the erroneous elements (see JSON reponse format) will be returned.

To override this, you may specify "ignore_errors=True" in the URL. In this case the import just skips the erroneous records and always returns a success message (error messages are stored, but not returned). Note that "ignore_errors" is not recommended to be represented in regular a user interface, but just used manually if at all necessary (e.g. in manual pre-population of data).

Note: In contrast to validation errors, IntegrityError and IOError exceptions during data import do not prevent or roll back any data import that happened before the exception, and the returned element tree does not contain any error attributes, and these exceptions can not be overridden by "ignore_errors" either.

Onvalidation/Onaccept Callbacks

Import of records happens almost as if they were entered in HTML forms, i.e. onvalidation- and onaccept callbacks are executed as usual. They receive a pseudo-form as parameter, which is Storage() instead of Form(). Other than Form() objects, the pseudo-forms contain only form.vars (as usual, so most of the callbacks should work without change) and a form.method (which contains either "create" or "update") to indicate the action (which, in case of XML imports, can not be determined from the request).

NOTE: Never redirect from onvalidation or onaccept functions - this would break the XML import! Instead, set a flag in response.s3, and let the calling controller redirect upon this flag.


XML imports/exports are fully Auth-enabled, i.e. all actions are checked for permission and support auditing as specified in the Settings.

Response Format

The response object to create, update or delete requests in both XML as well as JSON representations always contains a JSON body like:

    "status": "success",                 // "success" or "failed"
    "statuscode": "200",                 // HTTP Status Code
    "message" : "Ok",                    // Message as clear text (optional)
    "tree" : {                           // Tree object in the JSON response indicates an error
                                         // object containing the originally submitted data tree as described above
        "$_my_resource": {

            "myfield": {
                "@value": "xxxx",
                "$": "Bullshit",
                "@error": "Validation Error: myfield must be integer!"    // @error indicates an error for this field
  • tree is only returned in case of an error during Create or Update actions
  • @error attributes can be re-sent (will be removed by the controller)

UUID Mapping and Matching

On data export, all references are mapped from internal id's to uuid's - given that uuid's are present in the referenced table, otherwise the reference field is not represented in XML or JSON at all.

On data import, all references are mapped back from uuid's to internal id's, provided that the referenced record (with that uuid) exists in the database, otherwise the reference field is not imported (get's a default value).

On data import with create method, records with matching UUID's will automatically get updated instead of newly created.

Therefore, for resources that have to be exchanged, the use of UUID's is highly recommended.

In-line transformation with XSLT

No image "s3xml.png" attached to S3/S3Resource

The XML/JSON interface uses XSLT to transform data from/to the raw XML/JSON format into foreign formats.

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="" version="1.0">
    <xsl:output method="xml"/>
    <xsl:template match="/">
        <xsl:copy-of select="."/>

This is just an example template for import/export, but it is not used. Instead, when you specify the native formats "xml" or "json", the raw formats described above are used.

To enable other formats, you have to:

For import:

  • put an XSLT template for import into static/xsl/import and name the template <format>.xslt (e.g. pfif.xslt)
  • in the file models/ add the <format> name to this line:
    shn_xml_import_formats = ["xml", "pfif"]

For export analogous:

  • put an XSLT template for export into static/xsl/export and name the template <format>.xslt (e.g. pfif.xslt)
  • in the file models/ add the <format> name to this line:
    shn_xml_export_formats = ["xml", "pfif"]

From there, you can use that format name as either extension or ?format= option in requests:





and the corresponding XSL template will now be used at import/export from/into that format.

Note: "json" and "xml" must be in the format lists in models/!


Attachments (2)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.