Yes, we should definitely split the pieces into separately
downloadable components. This has been a goal for a while, but we've
gotten sidetracked with a whole bunch of other stuff. :)
Anybody care to tackle the separation of Django templates? The main
thing is decoupling it from django.core.settings (and, hence,
DJANGO_SETTINGS_MODULE), of which I'm not sure what the best approach
would be. Note that in the magic-removal branch, the template system
has been moved from django.core.template to django.template, so it's
already nicely modularized in terms of where the code lives.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
When the template system is broken out a bit more, I'd be rather
interested in using it in a few of my own applications. I'll be happy
to contribute some time setting up the entry point stuff it will need
to be compatible with the template plug-in 'standards' being developed.
Cheers,
Ben
HAND,
(c)
--
Carlo C8E Miron, ICQ #26429731
--
Disclaimer:
If I receive a message from you, you are agreeing that:
1. I am by definition, "the intended recipient".
2. All information in the email is mine to do with as I see fit and
make such financial profit, political mileage, or good joke as it
lends itself to. In particular, I may quote it on USENET or the WWW.
3. I may take the contents as representing the views of your company.
4. This overrides any disclaimer or statement of confidentiality that
may be included on your message.
But personally I find the idea of spliting them out awsome. Especially
the ORM because SQLObject isn't as good as the django solution.
--
I...@Holsman.net -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909
If everything seems under control, you're not going fast enough. -
Mario Andretti
There's currently a discussion about just that on the python web-sig
mailing list.
http://mail.python.org/pipermail/web-sig/2006-January/thread.html#1912
And here's how I adapated it in Pylons to automatically allow me to use
any of the template languages supporting it:
http://pylons.groovie.org/project/pylons/browser/trunk/pylons/util.py#L204
Also note that there is some code at the top of that file that handles
scanning the setuptools entry points to search for template languages.
I adapted my 'Buffet' code from the Buffet project here:
http://projects.dowski.com/projects/buffet
This 'standard' is still being developed, but this current solution is
working right now and being used. Django could rather easily adapt the
same pieces of code to allow the use of these same template language
plug-ins.
As my interest is in using Django templates, if there's specific needs
that Django templates have that the current plug-in system doesn't
address I'll be happy to try and lobby on behalf of Django for any
changes necessary to support Django templates. AFAIK, the current setup
should work fine.
- Ben
> Anybody care to tackle the separation of Django templates? The main
> thing is decoupling it from django.core.settings (and, hence,
> DJANGO_SETTINGS_MODULE), of which I'm not sure what the best
> approach would be.
a simple solution would be to use lazy loading of the settings
module in django.template, change all template code to access
the settings via django.template.settings, and let an external
user configure the template package *before* loading the first
template:
from django import template
template.config(TEMPLATE_DIRS=(...))
t = template.loader(...)
where config does something like
class Settings:
TEMPLATE_DIRS = ()
DEFAULT_CHARSET = "utf-8"
...
def config(TEMPLATE_DIRS=(), **options):
global settings
new_settings = Settings()
new_settings.TEMPLATE_DIRS = TEMPLATE_DIRS
for k, v in options.items():
if not hasattr(new_settings, k):
raise some exception
setattr(new_settings, k, v)
settings = new_settings
to implement the lazy loading, relevant template entry points
(loader, template constructors, etc) must do
django.template.config_setup()
which does something like
def config_setup():
global settings
if settings is None:
from django.conf import settings
return settings
</F>
Should be doable since now settings are stored in an object and not a
module - and actually this would be nice to have for other situations,
too. I think about the Pasteification, it might benefit from this, too
- since this config setup could just happen in the thread as the first
thing in handling a request, so that switching settings becomes even
easier.
bye, Georg
I think this is an extremely good idea, and we should extended it
into other pieces of Django we'd like available as components -- the
ORM, the cache API, others?
Jacob