Consistent exception handling in templates.

[Tai Lee]

I'd like to raise the topic of exception handling in templates, to see
what people think of the current state and discuss possible
improvements.

I personally find it confusing to use and create template tags at
times, due to exception handling. Sometimes exceptions are supposed to
be silenced, and sometimes not.

The docs say that when writing custom template tags, the `render()`
function should never raise `TemplateSyntaxError`, but some of
Django's own template tags (e.g. `widthratio`) don't adhere to this
policy.

I have also had difficulty with inconsistent behaviour between
development and production environments, due to the `TEMPLATE_DEBUG`
setting. For example, if `TEMPLATE_DEBUG` is `False`, the `include`
template tag will fail silently when passed a string or context
variable. If `TEMPLATE_DEBUG` is `True` (often the case on local
development servers) it will raise an exception at compile time only
when passed a literal string argument, otherwise it will raise an
exception at render time (again, against the advice in the docs) when
passed a context variable. In order to mimic production behaviour in a
development environment, you must set `TEMPLATE_DEBUG` to `False`, and
then you miss out on useful debug information.

When it comes time to test, and you have a template tag that does
happen to raise an unhandled exception (e.g. `ValueError`), it will be
transformed into `TemplateSyntaxError` if `TEMPLATE_DEBUG` is `True`.
So you need to test for either exception in your tests, or override
the `TEMPLATE_DEBUG` setting so that you can expect one exception or
the other, or add a try/except block to the `render()` function of
your template tag and either raise `TemplateSyntaxError` all the time
(against the advice of the docs) or silence all exceptions, with
either option possibly hiding problems that exist elsewhere in the
code (in a function called by the template tag).

I'd like to see a move towards consistent exception handling in
templates for template tags and filters. I'd like to see no exceptions
silenced by default, but provide a way for template authors to
conditionally silence exceptions in fragments of their templates.
Perhaps with a block tag.

This should allow for consistent behaviour, make it easier to spot
errors during development, and give developers the option of silencing
specific exceptions when they need to do something conditionally, e.g.
include a template that may or may not exist.

I imagine that this would be a huge backwards incompatible change. Are
there any less severe alternative steps we could take to improve the
situation generally?

Would it be possible to make such a change by following a deprecation
path?

Should built-in template tags follow the advice given in the docs, and
never raise `TemplateSyntaxError` in their `render()` function?

Cheers.

-- 
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: Weekly check-in (this should be #5, right...?)

[akaariai]

On Jul 6, 1:11 pm, Michal Petrucha  wrote:

> Hmm, this is exactly what I had in mind when thinking about this
> problem. I see that even despite keeping the changes to a minimum, the
> patch looks quite big. I'll definitely review this once I start
> working on relationship fields.

No wonder the patch is quite big. I accidentally branched from the
conditional aggregation branch, so it has all the things in that patch
included. And that patch is much larger than the multicolumn_join
patch.

I pushed a new branch to github (https://github.com/akaariai/django/
tree/multicolumn_join), this time the patch is much smaller:  4 files
changed, 77 insertions(+), 63 deletions(-)

I will destroy the composite_join branch. I didn't like the
composite_join name anyways, multicolumn_join is much better
name... :)

 - Anssi

-- 
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: FilePathField and stale choices

[Daniel Swarbrick]

On Jul 7, 1:04 am, Luke Plant  wrote:
> That sounds like a reasonable idea to me, since doing it by default
> could impose a serious performance hit. In it's most naive form (i.e.
> making the 'choices' attribute a lazy list using
> django.utils.functional.lazy) this wouldn't be too hard to implement.
>
> Feel free to open a ticket for this.
>

Done - https://code.djangoproject.com/ticket/16429

-- 
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: Caching model choice fields in admin inlines.

[Vimukthi]

I have a formset in my application where there is a select field and
also a multiselect field in a form. In some object edit view, number
of times each form in the formset gets called increases with the
increase of number of relationships between objects in the db(see my
question on stackoverflow -
http://stackoverflow.com/questions/6591890/django-formsets-slow-on-many-to-many-relationships).
Because of the way formsets work this means the number of queries to
the db also increase and it causes an unacceptable latency in  the
view. Although caching is required in the case of multiple requests
for the same view, I think the first improvement that should be made
is to have the repeated form as a property of formset object(in the
first time it gets instantiated) and then use that property as
required. Do you see any problems with this?

On May 23, 8:29 pm, Sean Brant  wrote:
> If you have ever used a inline in the admin for a model that contained
> a model choice field you have probably noticed it has to query the
> database for each row to fill the select drop-down. This results in n+
> identical queries.
>
> I though it might be useful to have a way to tell a admin inline to
> cache the choices of fields. Here is some rough code that gets the job
> done::
>
>     from django.forms.models import BaseInlineFormSet
>
>     class CachedInlineFormSet(BaseInlineFormSet):
>         cached_fields = []
>
>         def _construct_form(self, i, **kwargs):
>             form = super(CachedInlineFormSet, self)._construct_form(i,
> **kwargs)
>             for cache_field in self.cached_fields:
>                 field = form.fields[cache_field]
>                 field.cache_choices = True
>                 choices = getattr(self, '_cached_%s_choices' %
> cache_field, None)
>                 if choices is None:
>                     choices = list(field.choices)
>                     setattr(self, '_cached_%s_choices' % cache_field,
> choices)
>                 field.choice_cache = choices
>             return form
>
>     class CachedTabularInline(admin.TabularInline):
>         cached_fields = []
>
>         def get_formset(self, request, obj=None, **kwargs):
>             formset = super(CachedTabularInline,
> self).get_formset(request, obj=None, **kwargs)
>             formset.cached_fields = self.cached_fields
>             return formset
>
>     class MyInline(CachedTabularInline):
>         model = MyModel
>         cache_fields = ['myfk']
>
> Im not super big on how this patches the classes in various places so
> i'm open to better suggestions. Is this something that the admin could
> benefit from or is this better kept as a 3rd party tool?

-- 
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: [GSoC form-rendering] Weekly Check-in

[Chris Beaven]

On Wednesday, July 6, 2011 2:30:12 AM UTC+12, Gregor Müllegger wrote:
>
> Hi, Chris.
>
> Seems that I'm now unemployed as GSoC Student,
> looks like you already did all the work! ;-)
>
I prefer to show prototype code than just discussing things. It's more fun 
:)
 

> Besides this, great work. If I understand the source code right (haven't 
> run
> it yet), then it's already feature complete, isn't it?
>
Thrown together in 1.5 days and not very tested, but yes, mostly feature 
complete.

I also like the idea of "extends", I will definitely bring this up to Carl's
> attention. I don't know if it's in the core devs taste to change the 
> meaning
> of a {% block %} slightly in the context of a form tag.
>
I don't know if it's in the other core devs taste either. I just decided 
it'd do for my demo. I don't really mind it, but I can see the potential 
confusion - it's not part of the tag's child_nodelists as it stands so you 
wouldn't be able to override it - and it wouldn't make much sense anyway 
because it wouldn't be out of the ordinary to use the same block name 
multiple times in the same template (inside of form tags).

Here's something for you to chew on, related to my earlier thoughts on 
needing to change the widget definition for a field:
It's not enough to just use a 'hidden' field template, because we also need 
error messages related to that field to show up as non_field_errors. So how 
do you think we should do that? (I have some ideas, but I'll let you think 
about it first)

>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/IMFMhkKnh9EJ.
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.