Since the release of 3.4.0 parts of NAV have been using the Python web framework Django for some subsystems/apps, starting with the new IP Device Info app.

This introduction to using Django with NAV assumes that the reader is familiar with Django, i.e. have read the Django tutorial and knows his way around the Django documentation.

As NAV has not used Django from the very beginning, NAV does not strictly follow the Django convention of multiple apps with their own models, views, etc. To plug NAV into the Django framework some glue is needed. This glue and other common Django-related code is located in the nav.django Python package, which is located in subsystem/lib-python/src/nav/django.

The usual Django settings file is located at nav.django.settings. The end-users does not need to modify this settings file when deploying NAV, as all options are derived from existing NAV configuration in i.e. the files nav.conf and db.conf.

Note that there is no INSTALLED_APPS setting. NAV does not use this setting at all, due to a different file organization than what Django expects. Following from this, Django does not have a concept of what is an app in NAV. An app is just defined in the minds of the developers. This also means that NAV to a very little degree may take advantage of the django-admin.py executable, including features like syncdb for creating database tables for new apps.

In nav.django.urls the root URL configuration for all things Django in NAV is located. The URLconf is roughly divided in two. The first part delegates various URL namespaces, like /ipdevinfo/, to the corresponding Django apps and their own URLconfs. The second part is URL patterns for non-Django NAV subsystems, like the report subsystem. The second part is used by Django apps to link to non-Django apps, through the use of the url template tag or the reverse() function, instead of using the archaic nav.web.urlbuilder.

Since before Django, NAV has been using the Cheetah template system. To enable the use of Django templates for Django apps, while still integrating with the existing template hierarchy of NAV, some shortcut functions has been created in nav.django.shortcuts. At the time of writing, the shortcuts are render_to_response(), object_list(), and object_detail(). render_to_response() is analogous to the well known django.shortcuts.render_to_response(), and object_list() and object_detail() are analogous to functions in django.views.generic.list_detail.

The difference between the original functions from Django and the ones provided in nav.django.shortcuts is that the NAV versions take an additional first argument, namely cheetah_template_func. cheetah_template_func is assumed to be a Cheetah template function, which returns a Cheetah template with a content_string variable. The shortcuts takes the content which Django normally would have returned, and inserts it into the content_string variable of the Cheetah template. In other words, a Django template is rendered as usual, and then the result are wrapped into a Cheetah template.

At the time of writing, nav.django.context_processors only contains one context processors: debug. If Django is run in debug mode, this context processors appends a sql_queries variable to the context of all templates, containing all SQL queries executed to generate the current page. This is useful for optimizing the use of the Django ORM.

TODO

TODO: File structure, etc.

TODO

TODO

TODO: Custom render_to_response(), etc.

TODO

TODO

TODO

NAV uses sessions for keeping track of logged in users. Currently, we are not using django.contrib.sessions, but are still using plain old mod_python sessions. The easiest way to get hold of the mod_python session in views is to use request._req.session, where request._req is the traditional mod_python request object.

TODO: Replace wrapping Django templates in Cheetah templates.

TODO