GvR prefers Django Template over Cheetah And Modularised Django

3 views
Skip to first unread message

Amit Upadhyay

unread,
Jan 31, 2006, 5:21:59 AM1/31/06
to django-d...@googlegroups.com
Hi all,

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

unread,
Jan 31, 2006, 10:04:14 AM1/31/06
to django-d...@googlegroups.com
On 1/31/06, Amit Upadhyay <upad...@gmail.com> wrote:
> 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

unread,
Jan 31, 2006, 3:38:32 PM1/31/06
to Django developers
Adrian Holovaty wrote:
> 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

unread,
Jan 31, 2006, 3:56:35 PM1/31/06
to django-d...@googlegroups.com
jfyi,
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

unread,
Jan 31, 2006, 4:22:01 PM1/31/06
to Django developers
Hehe. A month ago I tried to use the django template for my pocoo
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

unread,
Jan 31, 2006, 4:25:37 PM1/31/06
to django-d...@googlegroups.com
are you proposing a standard interface to templating languages in python
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

unread,
Jan 31, 2006, 5:00:27 PM1/31/06
to django-d...@googlegroups.com
On 01/31/06 22:25, Ian Holsman wrote:
> 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

unread,
Jan 31, 2006, 5:03:39 PM1/31/06
to Django developers
Yes, sort of. TurboGears is using what they're calling the "open
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

unread,
Feb 3, 2006, 4:28:03 AM2/3/06
to Django developers
Adrian wrote:

> 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

unread,
Feb 3, 2006, 5:03:20 AM2/3/06
to Django developers
>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:

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

unread,
Feb 3, 2006, 8:13:49 AM2/3/06
to django-d...@googlegroups.com
On Feb 3, 2006, at 3:28 AM, fre...@pythonware.com wrote:
> 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

unread,
Feb 3, 2006, 1:05:09 PM2/3/06
to Django developers
I've created a ticket for this task:
http://code.djangoproject.com/ticket/1321

Reply all
Reply to author
Forward
0 new messages