[Django] #35966: Support `check` for invalid `template_name` string in `TemplateView` and other related types

7 views
Skip to first unread message

Django

unread,
Dec 3, 2024, 3:10:54 AM12/3/24
to django-...@googlegroups.com
#35966: Support `check` for invalid `template_name` string in `TemplateView` and
other related types
-------------------------------------+-------------------------------------
Reporter: Sobolev Nikita | Type: New
| feature
Status: new | Component: Core
| (Management commands)
Version: 5.1 | Severity: Normal
Keywords: checks, views, | Triage Stage:
template_name | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
`python manage.py check` helps us to find a lot of problems before
actually running the project itself / tests for it.

I think that one thing that we can also check statically is
`template_name` strings in different views that we have set-up in `urls`.
These templates can be found using regular Django machinery and help
finging issues sooner.

Basically, I expect:

```python
from django.views.generic import TemplateView

class MyView(TemplateView):
template_name = 'my.html'
```

to raise an error during `python manage.py check` if `my.html` cannot be
found with `TEMPLATE` loader settings. When `MyView` is present in
`urls.py` as:

```python
urlpatterns = [
path('/whatever', MyView.as_view(), name='whatever'),
]
```

What do others think?
--
Ticket URL: <https://code.djangoproject.com/ticket/35966>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Dec 3, 2024, 3:11:32 AM12/3/24
to django-...@googlegroups.com
#35966: Support `check` for invalid `template_name` string in `TemplateView` and
other related types
-------------------------------------+-------------------------------------
Reporter: Sobolev Nikita | Owner: (none)
Type: New feature | Status: new
Component: Core (Management | Version: 5.1
commands) |
Severity: Normal | Resolution:
Keywords: checks, views, | Triage Stage:
template_name | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Sobolev Nikita:

Old description:

> `python manage.py check` helps us to find a lot of problems before
> actually running the project itself / tests for it.
>
> I think that one thing that we can also check statically is
> `template_name` strings in different views that we have set-up in `urls`.
> These templates can be found using regular Django machinery and help
> finging issues sooner.
>
> Basically, I expect:
>
> ```python
> from django.views.generic import TemplateView
>
> class MyView(TemplateView):
> template_name = 'my.html'
> ```
>
> to raise an error during `python manage.py check` if `my.html` cannot be
> found with `TEMPLATE` loader settings. When `MyView` is present in
> `urls.py` as:
>
> ```python
> urlpatterns = [
> path('/whatever', MyView.as_view(), name='whatever'),
> ]
> ```
>
> What do others think?

New description:

`python manage.py check` helps us to find a lot of problems before
actually running the project itself / tests for it.

I think that one thing that we can also check statically is
`template_name` strings in different views that we have set-up in `urls`.
These templates can be found using regular Django machinery and help
finging issues sooner.

Basically, I expect:



{{{
from django.views.generic import TemplateView

class MyView(TemplateView):
template_name = 'my.html'
}}}



to raise an error during `python manage.py check` if `my.html` cannot be
found with `TEMPLATE` loader settings. When `MyView` is present in
`urls.py` as:


{{{
urlpatterns = [
path('/whatever', MyView.as_view(), name='whatever'),
]
}}}



What do others think?

--
--
Ticket URL: <https://code.djangoproject.com/ticket/35966#comment:1>

Django

unread,
Dec 3, 2024, 5:13:08 AM12/3/24
to django-...@googlegroups.com
#35966: Support `check` for invalid `template_name` string in `TemplateView` and
other related types
-------------------------------------+-------------------------------------
Reporter: Sobolev Nikita | Owner: (none)
Type: New feature | Status: closed
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution: wontfix
Keywords: checks, views, | Triage Stage:
template_name | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Sarah Boyce):

* component: Core (Management commands) => Core (System checks)
* resolution: => wontfix
* status: new => closed

Comment:

Hi Sobolev, thank you for the ticket
Before we accept new features for Django, we first want to see this being
discussed with the broader community to check we're all aligned for the
addition.
Could you start a new conversation on the
[https://forum.djangoproject.com/c/internals/5 Django Forum]? You'll reach
a broader audience and receive additional feedback

I'll close the ticket for now, but if the community agrees with the
proposal, please return to this ticket and reference the forum discussion
so we can re-open it.
For more information, please refer to
[https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
features/#requesting-features the documented guidelines for requesting
features].

---

In terms of my thoughts... This would be for anything that inherits from
`TemplateResponseMixin`. People can define their own `get_template_names`
method (this either raises a `ImproperlyConfigured` error or returns a
list of template names). Note that you can also have `template_name` as an
init kwarg like `MyView.as_view(template_name="my.html")`. So in short, it
might not be as simple as it seems, hence I'd like to see a bunch of
people saying they'd find this useful 👍
--
Ticket URL: <https://code.djangoproject.com/ticket/35966#comment:2>
Reply all
Reply to author
Forward
0 new messages