#1321 closed task (fixed)
Modularised Django
Reported by: | Owned by: | Adrian Holovaty | |
---|---|---|---|
Component: | Core (Other) | Version: | |
Severity: | major | Keywords: | |
Cc: | upadhyay@… | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Django is the most ass kicking webframework ever created. So why not share knowledge and modules? There is a discussion on django-developers about split out the template engine and the ORM System.
I personally like the idea but how should this work?
- these module must not read DJANGO_SETTINGS_MODULE and other dependencies
- they shouldn't require a download of the whole django framework
- when used in django there shouldn't be too many (none) changes which might break backwards compatibility
The problem will be the last point in combination with the first two :-)
Attachments (2)
Change History (13)
comment:1 by , 19 years ago
Cc: | added |
---|
comment:2 by , 19 years ago
comment:3 by , 19 years ago
That sounds like a very good idea, Fredrik; a patch would be quite welcome.
comment:4 by , 19 years ago
oh, please do that in the magic-removal branch, as that already has the refactored settings stuff.
comment:5 by , 19 years ago
I paste binned this for Adrian's review during the sprint, but in case it gets lost I'm adding it here. It's a patch that gets the template part of Django modularised, and provides a bit of a basis for doing the rest. My notes are below, the patch is attached
The basic implementation is as below:
In django/template/__init__.py
replace
from django.conf import settings
with:
settings = LazySettings()
In django/template/*.py
replace:
from django.conf import settings
with:
from django.template import settings
Then there are a few bits and pieces that have to be changed to keep 'settings' from looking itself up in django.conf too early.
Some issues:
- Tests - I've added some, but because of DJANGO_SETTINGS_MODULE the test modules can't be imported into the existing test suite. Instead I've created a 'standalone' dir that contains test scripts that should just be run using system(), and a script 'standalone_tests.py' that executes all the scripts in that dir.
- Default template settings: at the moment I've just duplicated the relevant parts of global_settings in
django/template/__init__.py
. This obviously isn't OAOO, but I'm not sure how else to do it without ending up in all kinds of import loops or defeating the aim.
- The 'configure' method for template: maybe this should just have a list of explicit keyword arguments instead of having the TemplateSettings class.
- LazySettings - this bit is actually reusable for modularising other parts of the system. It might not want to live in datastructures though.
by , 19 years ago
Attachment: | modularised_templates.diff added |
---|
Patch to begin implementation of this ticket
by , 18 years ago
Attachment: | standalone-django.diff added |
---|
An updated version of Luke's patch that tries to work for all cases.
comment:6 by , 18 years ago
This latest patch uses Luke's ideas and tries to make them work for all Django subsystems. There is nothing specific about the templating system in there now. Documentation patches included, so usage should hopefully be clear. Can't test it yet as part of the automated test suite (still working on that), but running tests/othertests/templates.py on its own will test these changes (it is forced to run in standalone mode).
comment:7 by , 18 years ago
I'm looking at this patch...
Why is LazySettings.__setattr__()
using this:
self.__dict__['_target'] = value
...instead of this?
self._target = value
comment:8 by , 18 years ago
adrian: I think that originally came from me tying myself in knots trying not to trigger __getattr__
from __setattr__
in the case where you are trying to set the '_target' attribute. I think the method should look like this:
def __setattr__(self, name, value): if name == '_target': setattr(self, '_target', value) else: setattr(self._target, name, value)
comment:9 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I can whip up a patch based on my proposal, in case anyone's interested (in brief: lazy access to the settings object/module, users may call django.template.setup before doing anything else if they don't want django's default setup).