Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.
Hi Django users,
We made at our company, City Live, a template tag you may be
interested in.
It's a try/catch statement. When anything in the try block fails, a
traceback through all the included templates is shown.
A good approach would be to include {% try %} ... {% endtry %} in the
base template of the whole site, so that any template rendering error
will be caught.
If you prefer a custom message instead of the traceback, the following
is also possible:
{% try %} ... {% except %} custom error message {% endtry %}
Screenshot of the traceback, embedded in our site:
http://github.com/citylive/Django-Template-Tags/blob/master/screenshots/traceback.png
Source:
http://github.com/citylive/Django-Template-Tags/blob/master/templatetags/debug.py
It depends on this {% stylize %} template tag and pygments for the
highlighting.
http://github.com/citylive/Django-Template-Tags/blob/master/templatetags/stylize.py
All feedback is welcome!
Jonathan
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.
On Mar 5, 5:49 pm, Jared Forsyth wrote: > I presume these only get shown with DEBUG turned on? Yes, they are only shown when DEBUG is on: see line 163: http://github.com/citylive/Django-Template-Tags/blob/master/templatetags/debug.py#L163 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.
On Mar 5, 6:59 pm, Jared Forsyth wrote:
> On a related note, is there a way to tell templates *not* to fail silently?
> (most tags etc. do)
> for testing/debugging purposes?
I don't think that all template tags fail silently.
Lookup of variables does always fail silently. That is, when a
variable is not found in the context, it will automatically evaluate
to None. So {{ non_existing_var }} will do nothing, but also {% if
non_existing_var %} ... {% endif %} won't do anything.
{% url name param %}, for instance won't fail silently when reverse
doesn't find a match.
Also, all the template tags that I write for my own use won't fail
silently, because I dislike that behavior.
Probably, if we don't want template tags to fail silently, all we have
to do, is patch the resolve call of variables which is done in most
template tags during the rendering.
Variable('varname').resolve(context)
I will look into this. It should be easy to change that behavior. (and
possibly allow {% try %} ... {% endtry %} catch the variable resolve
error.)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Template Compilation
Just a few thoughts, this is my idea and I'm not an expert at
compilers, so forgive me if I'm somewhere wrong.
(1) For me, personally, I think the scoping of variables should be
kept inside a block.
{% with "x" as x %}
{% with "y" as x %}
{% endwith %}
{{ x }}
- you would print "y", because you don't pop the context, while
the current template engine would print "x" (no? i didn't test it)
{% endwith %}
(2) Another issue will occur during a rendering error. What if a
template tag throws an exception? The traceback will show the trace
through the generated code, instead of the original templates.
(3) You're code snippets in the examples you are giving are not
equivalent. The second omits at least four print statements, and what
is say in (4) below. So, the timing is not really worth that much.
(4) How would you compile {{ a.b }} ? I think this can be interpreted
as either a.b(), a[b], or a.b
Python is typed dynamically. So, everytime you want to read out
{{ i }}, this should be changed to:
var_i = i() if callable(i) else i
(5) Be sure that custom template tags, like {% filter escape %} ... {%
endfilter %} still work. A separate result[], to capture the content
of this tag, and apply the filter, is required.
(6) I think that the code generator / compiler you are planning to
write, will be hard to maintain and hard to debug. Because compilers
need to evaluate several ways of how your source code could be written
in the destination language, it should decide which route will mostly
lead to the fasted path at runtime... The dynamic behavior of python
will make it difficult. Compare that to the very clean template.Node
structure, which is understandable for Django developers.
Correct me if I'm somewhere wrong, but I think that the slowness of
the current Django template engine is caused mostly because of the
pushing/popping of contexts and the expensive Variable.resolve. I
think that precompiling the templates to python code and further into
binary, would at most result in 2x the performance.You're proposing to
change the context behavior, are you planning to change the resolve
method also, in order to improve the performance? That and giving up
on the custom template tags, makes me think this is just another,
maybe better, but not really compatible template language.
At the positive side: some things can be improved by the preprocessor.
{% spaceless %} ... {% endspaceless %} can be executed at runtime.
b.t.w. I wrote a compiler for a Python based template language once.
It worked pretty well, also by compiling the template to python
(*.pyc) binary files. (The project is almost dead now, because I
started using Django now for most of my websites.)
http://code.google.com/p/python-pages/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.
On Mar 6, 3:36 am, Leo wrote: > This is really cool, thanks for sharing it! > > One small question though, would it be better to check TEMPLATE_DEBUG > instead of DEBUG > -http://docs.djangoproject.com/en/dev/ref/settings/#template-debug > ? Yes, TEMPLATE_DEBUG would be better indeed. Thanks. I'll change that. Now, I'm also planning to show the locals() for each frame. (Similar to the original django traceback) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.
> This looks really interesting. Is this something that could be
> integrated into Django's template page itself? It strikes me that this
> sort of feedback would be a good addition to Django's own debug page,
> rather than requiring end users to pepper debug tools like try-catch
> block in their template code.
Hi Russ,
You mean, whether this could replace the traceback from Django without
requiring you to have a {% try %} block in the template?
I'm not 100% sure, but it should be possible to design middleware
which will catch any exception if TEMPLATE_DEBUG and DEBUG are True,
and return this traceback instead.
Certainly something I will take a look at next week.
Jonathan
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: {% include_partial %} template tag
Something related, that we could really use is passing not just
variables to the include, but also blocks. I tried to implement a
template tag for this, but it doesn't work together with how Django
replaces blocks in the extended template at compile time instead of
during the renderering.
I would like to do:
## in the main template:
...
{% include "decorator.html" %}
{% block "content" %}
...
{% endblock %}
{% endinclude %}
...
## In decorator.html
{% block content %}{% endblock %}
##
So, the main templates includes decorator.html, but replaces the inner
block "content", by the block it passes to the include.
The decorator pattern, wraps the input in some nodes.
There are use cases where this is required to keep the templates DRY.
I think only a few templating languages are able to do this.
The .NET framework supports the design pattern pretty well, as far as
I remember.
The alternative in this particular example is to use two include tags
"before.html" and "after.html", but is ugly because the opening and
closing html tag are separated over different files.
-- Jonathan
On 8 juin, 19:47, Gregor Müllegger wrote:
> Also +1 from me for extending the include tag instead of having a new one.
>
> Bye default it should keep its behaviour and use the current context
> for the included template. Marco's use of a new, clean context
> (demonstrated with the snippet below) is also possible to support.
>
> {% if label %}
> {{ label }}
> {% else %}
>
> You can just pass in an empty string, like one of the following three
> examples:
>
> {% include "part.html" with label= title=obj.title %}
> {% include "part.html" with label="" title=obj.title %}
> {% include "part.html" with "" as label and obj.title as title %}
>
> (I don't want to propose the implementation of all three syntaxes. I
> just want to demonstrate that all possible syntaxes can handle Marco's
> usecase.)
>
> --
> Servus,
> Gregor Müllegger
>
> 2010/6/8 burc...@gmail.com :
>
>
>
> > I'd suggest to change both include and with/blocktrans syntax into
> > more programmer-friendly style:
>
> > {% include "part.html" title=obj.title|capfirst main_class="large" %}
>
> > This is both more dense, and from quick grasp you can see where are
> > the delimiters ("as" is not so good for this).
>
> > Also I think we need an argument to tell that outer context is passed
> > inside.
>
> > On Tue, Jun 8, 2010 at 11:30 PM, Gonzalo Saavedra
> > wrote:
> >> I'm +1 on the optional "with" parameter for {% include %}. -1 on
> >> adding a new tag for this.
>
> >> I also use {% with %}{% include %} a lot in templates but we should
> >> follow with/blocktrans syntax for consistency:
>
> >> {% include "part.html" with obj.title|capfirst as title and "large"
> >> as main_class %}
>
> >> A related proposal for the "with" tag: It'd be nice to support more
> >> than one variable definition (as blocktrans does):
>
> >> {% with "a" as var1 and "b" as var2 %}...{% endwith %}
>
> >> The current solution is nesting "with" tags, which is not very pretty.
>
> >> gonz.
>
> >> 2010/6/8 Marco Louro :
> >>> Gabriel,
>
> >>> I only made that decision because I didn't see the need to have whole
> >>> context, and the only time I have needed it was because of the {%
> >>> csrf_token %}. This is just my use-case, but I understand that other
> >>> people might want to use it differently. I don't think it makes much
> >>> of a difference, a clean context may avoid some collisions from time
> >>> to time, but it may have bigger drawbacks for other people.
>
> >>> Hi Jeliuc,
>
> >>> No, I don't.
>
> >>> On Jun 7, 7:59 pm, Gabriel Hurley wrote:
> Extending the include tag seems like a fantastic idea! I end up
> writing the {% with %}{% include %} combo all the time for my reusable
> template snippets.
>
> However, I feel like selectively clearing the context inside a
> template tag is asking for trouble and/or confusion. It also sounds
> like it goes against Django's "templates require no knowledge of
> programming" principle. While I can see how you might run into context
> name collisions in a *very* large or complicated project, the right
> solution there seems like it ought to be to clean up your context and/
> or templates outside of the template itself... Even in projects with
> dozens of installed apps (both my own and third-party ones mixed
> together) I've never had that problem where two minutes of tweaking
> couldn't fix it for good.
>
> I'm certainly not saying you don't have a use case for it, or that it
> wouldn't be extremely helpful to you. Just that having a tag that
> clears the context sounds fishy to me...
>
> All the best,
>
> - Gabriel
>
> On Jun 7, 10:52 am, Marco Louro wrote:
>
> > I'd prefer extending the {% include %} tag actually, but didn't of
> > that in the first place.
> >> [...]
>
> >> --
> >> You r
Template preprocessing (to improve template rendering speed, en page filesize)
Hi all,
At my current job, I spent a week of programming on a preprocessor for
Django templates.
In short, what it does is compiling the templates in a more compact
version, dropping all useless information and preprocessing
templatetags where possible. The Apache benchmark tools showed a page
load improvement up to twice as fast in Django 1.2, and 4 times as
fast in the older Django version and HTML pages are now only half as
big in filesize now.
It is completely transparent, there are no changes needed to the
templates, and should only be installed as a template loader (wrapping
around the original loaders).
What is does, in the Django language is:
* preprocess {% trans %} and {% blocktrans %} when they don't take
variables parameters. (the template loader will have a 'cache' for
each language)
* preprocess inheritance. Combining parent and child templates by
replacing the blocks, and filling in {{block.super}}. {% block %} tags
can be removed because all inheritance has been determined. (Note,
this doesn't work with {% extends variable_name %}, but I think it's a
bad idea to have variable inheritance. (but can be disabled if you
would need it.)
* preprocess {% include "path" %}, if path is not a variable.
* grouping {% load statements %}
* resolve all {% url %} when they don't take variable parameters.
* preprocess {% now "Y" %} (we will restart our server at least once,
after a year transition. :p )
* We have a few tags, like {% google_analytics %}, which constantly
output the same code, this is implemented as a custom preprocessor
extension for ourself.
Now, if the template is HTML, we do a little more optimizations:
* Remove all whitespace between block-level HTML tags
* Removing empty class attributes, like class="", (which may appear as
a result of class="{% block name %}{% endblock %}", where the child
template din't implement the block.)
* Merge all
i18n bug in template rendering.
I guess, we found a bug, not sure if it has been reported earlier and
whether this is the right place to report.
When a template contains translations in variables, like
{{ _("text") }}, the text seems to be translated already during the
creation of the Template object. Every following call of
Template.render() will output the translation which was made earlier.
(Possibly in the wrong language.)
Templates are cached in 'django.template.loaders.cached.Loader', so
this bug makes constructions like {{ _("text")|upper }} impossible.
=Test code: =
from django.utils import translation
from django.template import Template, Context
def language(language_code):
class with_block(object):
def __enter__(self):
self._old_language = translation.get_language()
translation.activate(language_code)
def __exit__(self, *args):
translation.activate(self._old_language)
return
with_block()
with language('en'): # Output 'Yes'
Template("{{ _('Yes') }}").render(Context({}))
with language('fr'): # Output 'Oui'
Template("{{ _('Yes') }}").render(Context({}))
with language('nl'): # Output 'Ja'
Template("{{ _('Yes') }}").render(Context({}))
with language('nl'): # create template, while environment language is
dutch
t = Template("{{ _('Yes') }}")
with language('fr'): # Render in French -> output is still Dutch
('Ja')
t.render(Context({}))
= Output =
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.utils import translation
>>> from django.template import Template, Context
>>>
>>>
>>> def language(language_code):
... class with_block(object):
... def __enter__(self):
... self._old_language = translation.get_language()
... translation.activate(language_code)
... def __exit__(self, *args):
... translation.activate(self._old_language)
... return
with_block()
...
>>>
>>> with language('en'): # Output 'Yes'
... Template("{{ _('Yes') }}").render(Context({}))
...
u'Yes'
>>>
>>> with language('fr'): # Output 'Oui'
... Template("{{ _('Yes') }}").render(Context({}))
...
u'Oui'
>>>
>>> with language('nl'): # Output 'Ja'
... Template("{{ _('Yes') }}").render(Context({}))
...
u'Ja'
>>>
>>> with language('nl'): # create template, while environment language is dutch
... t = Template("{{ _('Yes') }}")
...
>>> with language('fr'): # Render in French -> output is still Dutch ('Ja')
... t.render(Context({}))
...
u'Ja'
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: i18n bug in template rendering.
See also: http://pastebin.com/Wstya2C6 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: i18n bug in template rendering.
> You aren't supposed to use _('Foo') as a standalone variable.
> (see last paragraph
> herehttp://docs.djangoproject.com/en/1.2/topics/i18n/internationalization...)
Why shouldn't I use it as a standalone variable? (A language should
have a *context free* grammar, which means, that the underscore
function can be used in any variable. But that's no problem in
Django.)
That's not the point, the bug applies to any variable, template tag or
template filter parameter. It seems like a bug to me:
Any underscore function is translated during the initialisation of the
template, and that is wrong to me.
I guess, also for this one, like mentioned in the documentation.
{% some_special_tag _("Page not found") value|yesno:_("yes,no") %}
And I did a quick test:
with language('nl'):
t = Template("{% load i18n %}{{ 1|yesno:_('yes,no') }}")
t.render(Context()) # Will output 'ja'
with language('en'):
t.render(Context()) # Will still output 'ja', even if the language
is English now...
The underscore, which is a parameter for a template filter, is also
translated during the initialisation of the template...
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: i18n bug in template rendering.
Thanks Ramiro, we hope the patch will be applied in the next release. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Proposal for inclusion of two additional default template tags.
Hi all,
Like {% include %} and {% extends %}, I think we can include two more
template tags in Django's defaulttags for controlling the "render
flow". Click the links below for a usage example.
** A {% macro %} template tag
http://paste.pocoo.org/show/316592/
** And a {% decorate %} template tag:
http://paste.pocoo.org/show/316593/
I think they are generic enough to be included.
{% decorate %} implements a commonly used design pattern. (Also known
by XAML programmers.) It avoids the need of having to split a template
into a head.html and footer.html, which is a bad practice, because it
separates matching opening and closing tags over two files.
{% macro %} avoids the usage of external template files. I think it's
not worth the overhead of using an external file, when someone has to
repeat small parts of code in a template. And further, it's more clear
when the macro code is defined on top of the file where it's used.
The linked code samples have been used for several months now, without
any problems. (And at our office, we can't anymore live without.)
I hope for some feedback about what you think of including this in
defaulttags and wether you'd like to see something different.
- Jonathan
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal for inclusion of two additional default template tags.
Not really. But I believe it's still pretty fast using Django's render
engine. Probably about the same speed as using {% extends %} or {%
include %}
(By the way. We are working on a template preprocessor as well, and
every {% extends %}, {% include %}, {% macro %} and {% decorate %} is
preprocessed. So we can offer a new, smaller template to Django's
render engine without any of these tags. Rendering gets pretty fast ;)
We forbid here to use variables for template includes or inheritance,
so there's no reason to decide inheritance at run time.)
On 7 jan, 17:23, "Jonas H." wrote:
> On 01/07/2011 05:11 PM, Jonathan S wrote:
>
> > ** And a {% decorate %} template tag:
> >http://paste.pocoo.org/show/316593/
>
> +1
>
> > {% macro %} avoids the usage of external template files. I think it's
> > not worth the overhead of using an external file, when someone has to
> > repeat small parts of code in a template.
>
> +1, but did you actually do some benchmarking on this?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal for inclusion of two additional default template tags.
> Regarding the macro-tag I think the idea is valid but I'd personally
> prefer a more flexible approach regarding variables being provided
> for the macro block. Something like Jinja's macro comes to mind where
> I can define parameters for each macro and then pass them in as needed
Jinja's approach does not work with the Django templates.
- The whitespace in the template tags does not work well.
- Calling the macro method as a Variable instead of using a template
tag can probably not be done without rewriting compile_filter
(variable resolving from context) from scratch. I'm not sure about
this.
I think passing variables to includes has been discussed before, and
if we implement the {% macro %} tag, it should be done in a consistent
way.
Currently, you would do:
{% with "var" as variable %}
{% callmacro "macro_name" %}
{% endwith %}
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Missing semi-colon
Hi Django admin developers,
Can you please insert a semi-colon in the following file, behind line
90?
django/contrib/admin/templates/admin/edit_inline/tabular.html
var updateSelectFilter = function() {
// If any SelectFilter widgets are a part of the new form,
// instantiate a new SelectFilter instance for it.
if (typeof SelectFilter != "undefined"){
$(".selectfilter").each(function(index, value){
var namearr = value.name.split('-');
SelectFilter.init(value.id,
namearr[namearr.length-1], false, "{% admin_media_prefix %}");
})
--> please insert semi-colon here.
$(".selectfilterstacked").each(function(index, value){
var namearr = value.name.split('-');
SelectFilter.init(value.id,
namearr[namearr.length-1], true, "{% admin_media_prefix %}");
})
}
}
Thanks a lot,
Jonathan
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Missing semi-colon
Aparently, there are several semicolons missing at several places: django/contrib/admin/templates/admin/edit_inline/tabular.html lines 90, 94 and 124 django/contrib/admin/templates/admin/edit_inline/stacked.html lines 45, 48 and 78 Of course, this really is a minor issue, but easy enough to fix. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Missing semi-colon
Thanks, I made a patch and created a ticket. http://code.djangoproject.com/ticket/15490 On 23 fév, 13:48, Russell Keith-Magee wrote: > On Wed, Feb 23, 2011 at 8:24 PM, Jonathan S > wrote: > > Aparently, there are several semicolons missing at several places: > > > django/contrib/admin/templates/admin/edit_inline/tabular.html lines > > 90, 94 and 124 > > django/contrib/admin/templates/admin/edit_inline/stacked.html lines > > 45, 48 and 78 > > > Of course, this really is a minor issue, but easy enough to fix. > > Thanks for the report -- the best (and preferred) way to report this > is to open a ticket in Trac, ideally with a patch describing the > change you think needs to be made. > > 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 django-developers@googlegroups.com. > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Bug in ManyRelatedManager.get_query_set?
Hi, Some question about the current behavior in the ManyRelatedManager in django.db.models.fields.related. This manager has a method get_query_set. Why is it that the model name of the field where the foreign key is defined in, is passed to the database router? I think it's more logical to pass the model where the foreign key points to instead. Suppose we have a Model1 and Model2. And Model1 defines a foreign key to Model2. We have an instance model1. So, the property model1.model2_id exists. Now we retreive the model2 object by doing: "model1.model2". This will cause a query Model2.objects.get(id=...) to be executed. Model1 is defenitely not involved, so I think there's no reasen to pass Model1 to the router, instead of Model2. This patch should solve it: http://paste.pocoo.org/show/343888/ cheers, Jonathan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Template Compilation
Hi all,
I have also been working for about a year on such a template compiler,
and recently published it on Github. You may be interested in this
project:
https://github.com/citylive/django-template-preprocessor
** Short summary of what already is possible, and what still needs to
be done:
The template preprocessor consists of two parts.
-1-
A compiler which compiles the template in a compact version, (removing
comments, preprocessing l18n for all enabled languages, preprocessing
inheritance, includes, etc..., compressing HTML, CSS and javascript,
and combining external CSS/JS references.)
The output is a single template directory, which is still compatible
with the Django template render engine, but should render about twice
as fast.
-2-
A second compiler which takes the already manipulated parse tree of
-1-, and compiles it further into Python code. The output is a
directory of .py files for all templates. This part is still
experimental, and not extensively developed because it completely
bypasses Django's render engine and template parser at runtime. I had
the problem that it is incompatible with all custom template tags. So,
they need to be rewritten. I got rendering speeds of about 20 times as
fast as Django's own render engine.
So, what does it does at compile-time:
(a)
- remove django comments
- preprocess i18n tags as long as they don't contain variables.
- preprocess URLs when they don't contain variables.
- preprocess MEDIA_URL, SITE_DOMAIN and other static variables
- preprocess inheritance. (one important incompatibility: {% extend
"..." %} should only get a string as parameter, not a variable! But
honestly, I really don't know why someone would do that.
- preprocess {% include tags %}
- don't output any {% block %} tags, because they are meaningless now.
- group all {% load %} statements
(b) if this is a HTML template:
- parse the HTML tree. (the lexer will parse HTML in a 'django parse
tree')
- validation of HTML (note that we don't need to render any template
for validating html)
- merge internal CSS files
- compress HTML (remove whitespace)
- remove HTML comments
- parse the CSS/javascript.
- remove CSS and javascript comments.
- compress css
- compress javascript. (remove whitespace and shorten variable names.)
Basically, we all get these optizations at compile time. A very simpel
template loader will load the compiled template which renders much
faster by django's engine, because it has been optimized and is much
smaller now. This part is really stable.
The second compiler -2-, is able to take the output, and compile it
even further into python code, taking as much advantage as possible of
the Python interpreter.
It does also variable renaming like replacing:
{% with x as long_variable %}
with
{% with x as y %}
choosing the first free variable which has not yet been used inside
the inner scope.
This has been proven to work, but not yet recommended.
Let me know if you have other questions. There is more I have to tell,
but I'm a little busy right now...
Have a nice day,
Jonathan
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Template Compilation
Maybe. We solved that use-case by adding another custom directory to
TEMPLATE_DIRS when we had to override the base template. But I can
imagine that someone wants to be able to dynamically change the base
template, from inside a view or context processor.
This was a choice we made, because almost all the other features
depend on this. Having dynamic inheritance means having {% block %}
tags processed during rendering, and it means not being able to
process any of the HTML/css/js at compile time. For now, I have no
intension to change this behaviour, but of course anyone is welcome to
contribute.
Somehow, I'm still not really convinced of dynamic inheritance. It
feels like doing this in Python:
class A(random.choice([list,dict])): pass
On 28 mar, 18:13, Jacob Kaplan-Moss wrote:
> On Mon, Mar 28, 2011 at 11:04 AM, Dan Fairs wrote:
> > We don't have a core site base template. Each client on our system gets
> > their own, as IA/branding etc. varies considerably (and indeed includes
> > chunks of markup that the client supplies directly).
>
> ... and congratulations, you've successfully reversed-engineered the
> very use-case that led us to create this feature in the first place!
>
> Jacob
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal for Template Engine Refactoring
+1 on this. Are you planning on keeping the API for registering template tags compatible? (django.template.Library.register.tag) I think this may be required for backwards-compatibility, but personally, I'd like to see a cleaner API for this, which doesn't expose the parser details. (Writing template tags should not involve any token manipulation.) On 29 mar, 13:55, Armin Ronacher wrote: > Great. Google groups decided to reflow my mail. Here in actually > readable version:http://paste.pocoo.org/show/362024/ > > Regards, > Armin -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
