The Centre Registry is a Django web application and service that serves as administrative registry for CLARIN, documented on the CLARIN Trac.
api/KML/
Gives a KML file (Keyhole Markup) with geographical information about all Centres, for use in
mapping applications.
api/KML/[N[N[N[N[N[N]]]]].
Gives a KML file (Keyhole Markup) with geographical information about Centres of any type N, for
use in mapping applications. For example: api/KML/EBC
api/model/M, where M is one of the models in the administration interface CentreType,
Centre, Contact, Consortium, FCSEndpoint, URLReference, Organisation,
OAIPMHEndpoint, OAIPMHEndpointSet, SAMLIdentityFederation, SAMLServiceProvider:
Gives a JSON representation of all data belonging to that model in the database.
api/all_centres_full, for all Centres of any type with fully expanded relations into values
restxml/: gives a list of centres including the centre ID in XML.
restxml/n, where n is a centre ID: Gives detailed information about a centre in XML that is validated with this schema: http://catalog.clarin.eu/ds/ComponentRegistry/rest/registry/profiles/clarin.eu:cr1:p_1320657629667/xsd
Some services (WebLicht?) may depend on optional string-type properties of OAI-PMH endpoints that have been exported since the first API versions:
`WebServiceType` is the semantic indication of the kind of webservices offered.
`WebServicesSet` is just a name for the OAI-PMH set that contains the relevant web service metadata descriptions. It could be anything, so a harvester should be able to deal with arbitrary set names.
Django wants to detect modifications made to the data model of apps:
'Centre-Registry-config/manage.py' makemigrationsWhen you change an existing field, be careful to only change one property per makemigrations run (e.g, first change the field identifier, then the verbose_name string).
To show migrations previously made, and whether they have been carried out or not:
'Centre-Registry-config/manage.py' showmigrationsAfter making migrations, you will still need to apply them:
'Centre-Registry-config/manage.py' migrateAlways generate new a fixture after migrating. If you do not, your fixture will not correspond to the actual data model, and testing runs will fail outright.
For testing, you will need a sample of the data that obeys the data model. To generate such a fixture, run this:
'Centre-Registry-config/manage.py' dumpdata \
--format=json --indent 4 \
--natural-primary --natural-foreign \
--exclude=auth --exclude=sessions --exclude=admin --exclude=contenttypes \
--no-color --traceback -o \
'centre-registry-app/centre_registry/fixtures/test_data.json'When you change an existing field of some class in your data model, be careful to make only this single change per makemigrations run (e.g, first change the field identifier, then the verbose_name value), otherwise makemigrations will go awry.
Within your IDE such as IntelliJ IDEA, your project should have a Django 'facet' detected automatically. If so, you should have the complete testing 'run configuration' available.
First make sure that centre-registry-app and Centre-Registry-config are installed. Then run the test modules centre_registry.test_api and centre_registry.test_ui like so:
'Centre-Registry-config/manage.py' test centre_registryOr more selectively:
'Centre-Registry-config/manage.py' test centre_registry.{test_api,test_ui}The API and the UI are both tested by the continuous integration system.
After each commit (or PR), Travis CI will:
- build the project.
- execute the API tests.
- connect to Sauce Labs and run the UI (Selenium-based) tests targeting multiple browsers.
Current overall status of Travis build and tests:
In the last stage of the build and test process, the continuous integration system will run all UI tests for multiple browser and operating system combinations.
Test results breakdown per browser and operating system:
Automated cross-browser testing platform and open source ❤️ provided by Sauce Labs