Opened 7 years ago

Closed 7 years ago

#27819 closed Cleanup/optimization (wontfix)

Display a warning when django.views.generic.ListView assumes the default template name

Reported by: Maker Bajax Owned by: nobody
Component: Generic views Version: 1.8
Severity: Normal Keywords:
Cc: Nan Xiang Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I recently had an issue where it seemed that my code was trying to load a template for a ListView that I had defined previously, but renamed. Even though there was no more reference to the old template in another part of my code, it still gave me "Template not found." I spent a couple of hours scouring my code for references, deleting .pyc files and checking if the template had gotten cached in the database or something (It was a Django CMS project).

Lo and behold, after finally taking the time to set up a debugger and step through, I found the rogue template name was being derived from the app and model name as is done here (this is not the same version I'm using, but the line in question is identical):

https://github.com/django/django/blob/ff8711a825ea9bbe98e873d7aa28ce5135528fec/django/views/generic/list.py#L137

So with respect to that error message-- It was "Template not found." To the me at that time, that didn't mean, "You didn't define a template, so I assumed one for you," but "You handed me a bad template name."

I wasn't even aware that the ListView object could accept a template name (I'm still learning Django TBH) and I thought that was up to some other layer of the system to handle. At the time I had no idea where the template name could be coming from.

It would be nice if we could get a warning of some kind when a default is assumed like this. I know it's a design goal of Django to assume things that are left undefined, but maybe some warnings, especially at high verbosity, would be helpful. I even saw some places in the code where an "ImproperlyConfigured" exception was raised because I hadn't set a template name, but it was caught by some later code and everything carried on as if nothing was wrong.

Change History (4)

comment:1 by Tim Graham, 7 years ago

Type: UncategorizedCleanup/optimization

I can't think of a similar precedent elsewhere in Django for a warning or logging like that. The debug page usually display a list of template names it tried to load for a TemplateDoesNotExist exception. Was that not the case here?

in reply to:  1 comment:2 by Maker Bajax, 7 years ago

Replying to Tim Graham:

I can't think of a similar precedent elsewhere in Django for a warning or logging like that. The debug page usually display a list of template names it tried to load for a TemplateDoesNotExist exception. Was that not the case here?

Yes, but it wasn't helpful. It only showed the different file paths where it tried to locate the template, but it didn't show where the template itself was defined.

It'd be ideal if there was some way to add an extra blurb to the exception message when it actually doesn't find a template with the default name, but honestly I have no idea how to get the message from the point where it configures the ListView object to the point where the TemplateNotFound exception would be thrown. (leave template_name None during config, and look for the default name right before the template is loaded, maybe?) I thought it at least worth discussing because of the aforementioned ImproperlyConfigured exceptions for the exact mistake I made being caught and discarded.

comment:3 by Tim Graham, 7 years ago

Triage Stage: UnreviewedAccepted

Accepting for further thought, though I'm not sure if anything can be done.

comment:4 by Nan Xiang, 7 years ago

Cc: Nan Xiang added
Resolution: wontfix
Status: newclosed

As the ListView document:

We could explicitly tell the view which template to use by adding a template_name attribute to the view, but in the absence of an explicit template Django will infer one from the object’s name. In this case, the inferred template will be "books/publisher_list.html" – the “books” part comes from the name of the app that defines the model, while the “publisher” bit is just the lowercased version of the model’s name.

I suppose this ticket should be marked as wontfix.

Note: See TracTickets for help on using tickets.
Back to Top