The layout of the DINGOS Django application is as follows:
. ├── dingos │ ├── core │ │ ├── datastructures.py │ │ └── ... │ ├── management │ │ └── commands │ │ └── dingos_generic_xml_import.py │ │ │ ├── migrations │ │ ├── 0001_initial.py │ │ └── ... │ ├── templates │ │ └── dingos │ │ └── grappelli │ │ ├── base.html │ │ ├── details │ │ │ └── ... │ │ ├── includes │ │ │ └── ... │ │ ├── lists │ │ │ └── ... │ │ └── searches │ │ └── ... │ ├── templatetags │ │ └── dingos_tags.py │ ├── admin.py │ ├── filter.py │ ├── import_handling.py │ ├── importer.py │ ├── models.py │ ├── __init__.py │ ├── read_settings.py │ ├── urls.py │ ├── view_classes.py │ └── views.py
Internal libraries with helper functions are placed in the
folder. The most important library probably is
DingosObjDict, the dictionary structure into which
imported data is written.
DingosObjDict preserves the order in
which keys have been added and knows how to /flatten/ itself into
a list of facts.
This folder contains code for the command-line scripts that
can be executed via Django’s
interface. Refer to Django documentation on custom django-admin commands
for a description of how commands can be added.
DINGOS uses Django templates (see Django documentation on the template language)
for rendering HTML pages. These are located in the
The reason for this nesting is the following:
- by having
dingosin the file path, also other apps are able to refer to templates defined in DINGOS
- by having
grappelliin the file path, we are open to supporting different CSS frameworks at a later point of time: for supporting, e.g.,
bootstrap, a folder
templates\bootstrapwould have to be added and would then contain the bootstrap-based templates.
In order to learn how to use the Django Grappelli CSS, make sure to include
(r'^grappelli/', include('grappelli.urls')) in your url patterns in
You can then view the Grappelli CSS documentation under
<your Django server url>/grappelli/grp-doc/.
Configuration for the Django admin interface: via the admin interface, you can access the
DINGOS models. That is useful for viewing certain data (e.g., which namespaces do I have
in my system?) and configuring data (e.g., managing naming schemas via the
objects). Refer to the Django documentation on the admin site for details about
the contents of
admin.py – you may also want to have a look at
the documentation of Django Grappelli, since
admin.py uses some extensions
provided by Grappelli.
DINGOS uses the django-filter app to generate filters for list views. The
configuration for the filters is located in
filter.py: for background on
how to configure filters, please refer to the django-filter documentation.
models.py (see below), this is the heart of DINGOS: it defines the
DingoImportHandling that contains the
a highly configurable function for turning XML into DINGOS dictionary objects,
create_iobject, the function used to write a DINGOS dictionary object
InfoObject in the database.
The most important content of this file is the generic class
which provides the basis for easy implementation of import scripts to
be carried out via the command-line (see above under
and Django documentation on custom django-admin commands.
This file also contains a very simple generic XML importer, which is mostly for demonstration purposes.
The heart of DINGOS. The code is extensively documented; please refer to the
DINGOS Developers' Overview of the DINGOS models
for an overview.
DINGOS uses the
__init__.py file to define a number of defaults used
within the DINGOS code.
Code for reading DINGOS-specific settings configured in the Django settings
file(s). Some of the defaults defined in
__init__.py can be
DINGOS makes extensive use of Django’s class-based views (see the
Django documentation on class-based views). In
we define mixins (see also the Django documentation on using mixins in class-based views)
and base classes that are used for defining views
The DINGOS views. Refert to the Django documentation on class-based views.
When writing and testing views, do not even start without the excellent Django Debug Toolbar: it shows you, for example, how many which SQL queries were executed (which will help you to find the right configuration for the prefetch_related and select_related