On Sat, Dec 19, 2009 at 9:17 AM, Leaf <[email protected]> wrote: > 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.
In other news, the Python interpreter doesn't run Ruby code. This makes the Python interpreter completely non-portable, and makes it somewhat difficult to use alternate libraries since so much of the Python infrastructure depends heavily on code being written in Python. Seriously - Django's template language is what it is. It relies on template tags, and for very good reasons. Jinja is a different beast, with a different approach. Jinga's approach has advantages and disadvantages. Regardless of those advantages or disadvantages - if Jinja can't use Django's template tags, then quite frankly, that is Jinja's problem. If we can make a change that makes templates pluggable, we're only too happy to do so - and that's what has happened with #6262. However, we're not about to dramatically change the way Django templates work just to satisfy the requirements of a different template language. 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.
