On Tue, 2007-08-07 at 23:17 -0500, Gary Wilson wrote:
> Malcolm Tredinnick wrote:
> > I want to hear the use-case first. I may change my mind, but nobody's
> > come up with a good reason so far.
>
> How about looking at things from the opposite direction? Yes, it would
> be nice if the Django template system could be more easily used
> standalone, but by doing this it would also most probably allow Django
> to plug in other template engines more easily.
Again, this needs an answer to the question of what does "more easily"
mean. Currently, you import django.template, django.conf and make sure
you call django.conf.configure(...) prior to using the template stuff.
There's limited scope for streamlining there.
Maybe adding something like
django.conf.default_do_nothing_template_setup() reduces the complexity
and this was something we discussed as a possible enhancement when
django.conf.configure() was implemented. However, it won't be one size
fits all (if you ever want to use template loaders -- via extends or
include tags -- some configuration is required). It could live in the
django.template namespace so that only django.template needed to be
imported. Aside from that, what else comes wrapped up in this new
"easier" system.. I'm not trying to be difficult here; I genuinely don't
understand these perceived benefits and it's not for want of using the
system or thinking about the problem space.
> This feature could be a deciding factor for folks who would use Django
> "if only I could use my favorite XML-based templating system" or those
> switching from another framework with existing templates that they
> wouldn't want to totally rewrite.
Unconvinced.
The sort of questions I would ask (and answer) are:
Can Django's templating system be used standalone at the moment
without difficulty? Yes.
Can other templating systems already be used with Django without
needing to write lots of extra code? Yes.
We added the necessary features (configuration without requiring
DJANGO_SETTINGS_MODULE)for isolated template usage 18 months ago. What
needs to be made easier? Why can't whatever those changes are be done
without splitting?
How to make plugging in separate template engines easier is also
interesting, but, again, not particularly contingent on a split. It's
already possible and not particularly difficult: writing an appropriate
render_to_response makes things easier for some people, but by and
large, it's pretty much the same code you write now. When I did this for
a client late last year (using Cheetah throughout), the only real mod I
needed to make was a way to get a snapshot of the current Context's
top-layer of dictionary keys and values so that I could pass a real
dictionary around. Replacing the Context class with my own variant at
runtime fixed that. Including the method in core would help, though.
So the focus is on whether we need to make this easier and how. What
needs to be done there?
I really worry that we shouldn't be trying to reinvent Turbogears here.
If somebody wants plug-and-change-their-mind components, it's already
spelt "Turbogears" or "Pylons". Adding the necessary stuff to integrate
Django templates with Turbogears can't be that difficult (since it can
already be used standalone).
Please let's make sure we're solving worthwhile problems and trying to
solve the same problems. None of the stuff you've mentioned, Garry,
requires splitting templates off from Django. They're worthwhile things
to do on some level, but we can pretty much already do most of what is
needed, in practice.
It comes back to my original question for me: what can't be done now or
with a couple of small tweaks that can be done after the much more
disruptive change of splitting out the template system?
Regards,
Malcolm
--
Why can't you be a non-conformist like everyone else?
http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
