Changes between Initial Version and Version 1 of AppLoadingRefactor

06/11/12 15:24:29 (8 years ago)
Marc Tamlyn



  • AppLoadingRefactor

    v1 v1  
     1This is an attempt to bring together the current state and long term plans of how
     2application loading is done in Django, what it could do, and why.
     4== Application loading refactor ==
     6At present application loading is handled in different ways through Django.
     7Because of some of the limitations of Python, and some peculiarities of how
     8models work, modules should not be reimported. Consequently Django maintains
     9a global static, called the application cache. Models are imported from the
     10application cache transparently when interacting with the database. But
     11applications listed in `INSTALLED_APPS` contain more than just models. Some
     12contain template tags, `` files, `` files from
     13haystack, template folders and many other features which applications use to
     14inspect each other, or to contribute objects to a site-wide collection.
     16For the majority of applications, even reusable applications, anything more
     17than the current system is unnecessary. Models are automatically registered,
     18template tags can be loaded, and templates are available. (Tests are also
     19available but this is a separate issue.)
     21However, not every application has all of these components - there are many
     22useful pluggable applications which do not contain models, but must still be
     23registered in `INSTALLED_APPS`. A simple example is `django-pagination` -
     24which consists of a single template tag. This module must ship with an empty
     25`` module to allow it to be registered as an installed app, for that
     26template tag to be available.
     28The problem is even more difficult for ''"meta-applications"'' - that is to say
     29applications which exist solely to interact with other applications. The
     30canonical example of this is the django admin, but there are many third party
     31applications which do a similar thing. Haystack (the search engine framework)
     32is a good example. Also there are applications which have a plugin archicture,
     33whereby adding a second application to installed apps changes the behaviour of
     34the first application. All of these third party systems have implemented their
     35own ways to do this, with varying degrees of success.
     37This is an opportunity for Django to do something great for the third party
     38application community. It will be a very powerful tool, and opens up a range of
     39magical things which could be done. App loading is magical, but Magic is not
     40always a bad thing - most Django developers are very pleased they don't have to
     41individually register every model with Django as they do to register a model
     42with the admin. You just put it in the `` file and it works! This
     43will allow the magic to be more explicit, and ultimately more consistent
     44between third party applications.
     46This is a big change, and almost redefines what an "App" is within Django. To
     47my mind, an app was originally intended to be a fairly self contained part of
     48the system, normally in fact a self contained part of the ''Web site''.
     51=== Specification ===
     53Here is a specification of what an application is, and what it can do. Perhaps
     54not all of these points need to be implemented to be able to integrate this
     55refactor into core, but they should be considered to avoid future backwards
     58* An application is a self contained piece of code which '''contributes'''
     59  something to the site. It may contibute any number of the following:
     60    * models
     61    * templates
     62    * template tags
     63    * static files
     64    * admin configuration
     65  and these are just (some of?) the things which are picked up on by other
     66  parts of the Django core. Other things (seach indexes, migrations etc) may
     67  also be contributed by the application, and processed by other applications.
     69'''Note''' Some things are explicitly registered in settings, such as middleware,
     70database routers and cache backends. These things may be contained within
     71an application's code base, but they will not be registered automatically
     72by the presence of that application in the `INSTALLED_APPS`.
     74* An application may contain urls and views. These will generally be
     75  explicitly registered, but some applications may choose to attach dynamic
     76  urls offer a way of getting the urls from the application rather than
     77  directly (similar to how the admin does to it's site class).
     79* An application may modify another application. That is to say, an application
     80  may provide an interface on it's application class for other applications to
     81  modify it. This will facilitate a plugin architecture. A classic example of
     82  where this will be useful is a Content Management System.
     84* An application may depend on the presence of another application. It is
     85  preferable for the application to depend on a defined ''contract'' with another
     86  application, rather than explicity depend on that application. This should
     87  allow applications to be more loosely coupled, leading potentially to
     88  pluggable auth/messages applications. It also allows such applications to be
     89  tested perhaps without the presence of the dependant app - a mocked object
     90  may suffice.
     92* An application may inspect other applications to gather information about
     93  them. The system should provide tools to easily and safely access this
     94  information, whether it is accessing a folder or a python module. Where
     95  possible, we should modify parts of Django core & contrib to use this system.
     96  Examples would include the app directories template loader, admin site and
     97  template tag libraries.
     99* An exact copy of an application can be deployed within the same project by
     100  changing its label. This will have some subtle issues regarding imports.
     103=== Implementation plan ===
     105Application class. Talk about what APIs would bee needed on that class to
     106achieve the above. Separate by the above points. Ideally, does not need to be
     107contained within the python module it relates to (thus allowing me to subclass
     108an app's Application Class in my own project to tweak how it works, this may or
     109may not be better than passing configuration options)
     111Application cache. Discuss what hooks this would need to provide, including
     112signals, for the above to work.
     114Examine any backwards incompatibilities which may result. The app refactor
     115itself shouldn't introduce any, but the new functionality which it offers and
     116the resulting changes in other applications such as `contrib.auth` may need
     117deprecation paths.
     120=== Current status ===
     122Preston has merged master into the existing branch with work done by Jannis and
     123Arthur. (
     125We need to evaluate which of the current features are implemented, and which are
     128Update tests so that everything passes again, including outside of the appcache
     131Try to work out which parts of the implementation plan are tangential to
     132each other, and therefore could easily be worked on by other people.
Back to Top