GvR prefers Django Template over Cheetah And Modularised Django
Amit Upadhyay
One of the first thought that came to my mind when I read django documentation is, Django is really a set of related projects, Django ORM, Django Templates and Django Webframework, and can be used independently of each other. Came across this post by Guido: http://www.artima.com/weblogs/viewpost.jsp?thread=146606 where he likes Django Templates, but is bothered, a bit, by DJANGO_SETTINGS_MODULE thing.
Won't it be cool if django splits the tree into different reusable packages, developed and maintained by you folks only. One can say there are almost independent, but it requires lots of familiarity in django to understand this, an outsider may not get this idea initially. [and this also required a little API to initialize Django Templates or Django ORM]. Imagine Django Template and Django ORM becoming Python 2.5 standard modules!
Once people start using one component they may realize how good django really is, as GvR has, and maybe we will get close to a standard python web framework.
Regards,
--
Amit Upadhyay
Blog: http://www.rootshell.be/~upadhyay
+91-9867-359-701
Adrian Holovaty
> Won't it be cool if django splits the tree into different reusable packages,
> developed and maintained by you folks only. One can say there are almost
> independent, but it requires lots of familiarity in django to understand
> this, an outsider may not get this idea initially. [and this also required a
> little API to initialize Django Templates or Django ORM]. Imagine Django
> Template and Django ORM becoming Python 2.5 standard modules!
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
Ben Bangert
> 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.
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
Carlo C8E Miron
GvR wrote also:
>> Regarding a standard, there is sort of a standard
>> developing, that TurboGears has pioneered, and Pylons also
>> supports. It's called template plug-ins:
>> http://www.turbogears.com/docs/plugins/template.html
>
> Thanks for the pointer! Perhaps it is right -- if other frameworks support the same interface to
> templating plugins, then only one plugin (really a kind of adaptor) needs to be written for each
> templating package, and we can all be happy campers. Django designers, what do you think of > this idea?
>
>> You get a consistent interface to use a variety of
>> template languages of your choice. If the Django templates
>> can be used completely on their own, I'm not sure why they
>> aren't supporting this developing standard.
>
> They should. I hope they're listening!
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.
mitsuhiko
project but it ended up in rewriting the template engine. Not because
it was impossible to strip it out. (It worked quite well) but for pocoo
I wanted a better syntax for the filters.
But personally I find the idea of spliting them out awsome. Especially
the ORM because SQLObject isn't as good as the django solution.
Ian Holsman
ala WSGI but for templates?
--
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
Steven Armstrong
> are you proposing a standard interface to templating languages in python
> ala WSGI but for templates?
>
>
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
Ben Bangert
template plug-in engine" something or rather. The underlying effect is
it provides a unified way to render templates. It's still undergoing
some fine-tuning, and is not part of TurboGears itself. Here's the
'spec' for making a template language available for automatic plug-in
discovery:
http://www.turbogears.org/docs/plugins/template.html
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
fre...@pythonware.com
> 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>
hugo
>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:
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
Jacob Kaplan-Moss
> 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:
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
Armin Ronacher
http://code.djangoproject.com/ticket/1321