Okay, I can live with that. The "alternate template loader" system in
#6262 looks pretty nice. Unfortunately, I have already put a lot of
effort into writing a Jinja2 layer for Django (named, cleverly enough,
Djinja2) using the current, 1.1 template semantics that operates
without involving Django's template internals at all, but my
experience hacking up the Jinja2 Template class will prove invaluable
in getting working Jinja2 Loaders for Django.
Still, one of my concerns that I have had ever since I first started
writing Djinja2 was that the majority of functionality exposed to the
Django template language is exposed in custom tags. Though the tags
are powerful, they are completely non-portable, and will make it
somewhat difficult to use these alternative loaders since much of
Django's infrastructure, like the comments app, depends heavily on
custom template tags, even though a bit of forward-thinkingness in the
design of the template language could have made it easier to expose
the same functionality in a way that is more portable across template
languages, or even across changes in the internals of the template
language (the current tag system makes it impossible to refactor the
template engine in a substantial way without breaking every custom
tag). For example, Jinja2 lets you pass arguments to methods and use
the {% set var = expr %} tag to achieve the majority of what is
implemented in custom tags. I know too much logic in templates is bad,
but I also think that too much template logic in your logic is bad.
Any effort to effectively use a different template system with Django
will require reimplementing the custom tags.
On Dec 16, 6:50 pm, Russell Keith-Magee <[email protected]>
wrote:
> On Thu, Dec 17, 2009 at 2:56 AM, Leaf <[email protected]> wrote:
> > I know that you are all busy, but it has been over two weeks and there
> > has been no activity related to ticket #12292 (render_to_response
> > method on AdminSite and ModelAdmin) either on the list or on the Trac.
> > Has anyone looked at the ticket? What are the chances that this will
> > make it in for 1.2?
>
> I've given the ticket a quick look, and I've marked it wontfix. I'm
> not rejecting the idea of using non-Django template languages - just
> suggesting that there is a better way. Specifically, #6262/r11862
> should make it possible to write a Jinja/Mako template loader without
> needing any changes to Django core. The process for using non-Django
> template languages is documented in abstract terms, but the abstract
> example should map fairly closely to the Jinja experience:
>
> http://docs.djangoproject.com/en/dev/ref/templates/api/#using-an-alte...
>
> Yours,
> Russ Magee %-)
--
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.
