devel:django_introduction
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
devel:django_introduction [2008/08/25 08:27] jodal Upgrade to Django 1.0 done. |
devel:django_introduction [2008/08/28 10:09] morten fix details of sessions |
||
|---|---|---|---|
| Line 18: | Line 18: | ||
| ==== URL configuration ==== | ==== URL configuration ==== | ||
| - | 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''. | + | In ''nav.django.urls'' the root URL configuration for all things Django in NAV is located. ''nav.django.urls'' is not only a module, but also a package. The ''%%__init__.py%%'' file in the package imports all submodules it can find in the file system, calls ''get_urlpatterns()'' on all the submodules, and combines the results into one ''urlpatterns'' list, as all Django URL configurations does. |
| + | |||
| + | In other words, when creating a new Django app in a branch of its own, you simply drop a new submodule for your app into the ''subsystem/lib-python/src/nav/django/urls/'' folder, run ''make install'' in ''subsystem/lib-python/'' and then the NAV installation will find your app. If somebody else runs ''make install'' in their version of ''subsystem/lib-python/'' they will not overwrite the URL configuration for your new app, unless they use exactly the same name for the submodule as you did. | ||
| + | |||
| + | === nav.django.urls.urlbuilder === | ||
| + | |||
| + | There is one special submodule named ''nav.django.urls.urlbuilder''. This is simply a Django replacement for the archaic ''nav.web.urlbuilder''. It is used by Django apps to link to non-Django apps, like the report subsystem, through the use of the ''url'' template tag or the ''reverse()'' function, instead of using the archaic ''nav.web.urlbuilder''. From your code's point of view, the URL configurations in ''nav.django.urls.urlbuilder'' is used as any other URL configuration in NAV. | ||
| ==== Shortcuts ==== | ==== Shortcuts ==== | ||
| Line 111: | Line 117: | ||
| ==== mod_python and Django sessions ==== | ==== mod_python and Django sessions ==== | ||
| - | 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. For now, 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. In the future, one should look into using Django's authentication and session frameworks. | + | NAV uses sessions for keeping track of logged in users. Currently, we are not using ''django.contrib.sessions'', but are still using a session library developed specifically for NAV. This session library attaches session objects to ''mod_python'''s request objects. For now, the easiest way to get hold of the NAV session in views is to use ''request._req.session'', where ''request._req'' is the traditional ''mod_python'' request object. In the future, one should look into using Django's authentication and session frameworks. |
| ==== Base template using Django templates ==== | ==== Base template using Django templates ==== | ||
| Line 120: | Line 126: | ||
| NAV should certainly start using unit testing. Tests for i.e. ''nav.web.ipdevinfo'' could for example go into ''nav.web.ipdevinfo.tests'', but this should be synchronized with Django conventions, and one must also find a way to run the tests, most probably through a custom test runner or something. The point is, one needs to give this some thought, and the sooner the better. New Django apps in NAV should really have unit tests from the start. | NAV should certainly start using unit testing. Tests for i.e. ''nav.web.ipdevinfo'' could for example go into ''nav.web.ipdevinfo.tests'', but this should be synchronized with Django conventions, and one must also find a way to run the tests, most probably through a custom test runner or something. The point is, one needs to give this some thought, and the sooner the better. New Django apps in NAV should really have unit tests from the start. | ||
| + | |||
devel/django_introduction.txt · Last modified: 2010/01/13 11:30 by eide
Page Tools
