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

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

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

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",

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

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

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

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

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

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

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

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

Re: Proposal for inclusion of two additional default template tags.

" <jo...@lophus.org> 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 t

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

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,

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

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 <russ...@keith-magee.com> wrote: > On Wed, Feb 23, 2011 at 8:24 PM, Jonathan S <jonathan.slend...@gmail.com> > wrote: > > Aparently, ther

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

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:

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

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