Move all custom form rendering to form templates #6905

New Issue

adam · 2025-12-29T19:46:32+01:00

adam commented

2025-12-29 19:46:32 +01:00

Originally created by @jeremystretch on GitHub (Aug 29, 2022).

Proposed Changes

There are several places within NetBox where we define non-standard HTML templates for views in order to customize how forms are rendered. We should move all such logic into form-specific templates.

Justification

Django 4.0 introduced template-based form rendering, which enables the creation of a template for a specific form without having to override the template for the view in which it's rendered. This should help clean up the template code a bit.

Originally created by @jeremystretch on GitHub (Aug 29, 2022). ### Proposed Changes There are several places within NetBox where we define non-standard HTML templates for views in order to customize how forms are rendered. We should move all such logic into form-specific templates. ### Justification Django 4.0 [introduced](https://docs.djangoproject.com/en/4.1/releases/4.0/#template-based-form-rendering) [template-based form rendering](https://docs.djangoproject.com/en/stable/ref/forms/api/#django.forms.Form.render), which enables the creation of a template for a specific form without having to override the template for the view in which it's rendered. This should help clean up the template code a bit.

adam added the type: housekeeping label 2025-12-29 19:46:32 +01:00

adam closed this issue

2025-12-29 19:46:32 +01:00

adam commented

2025-12-29 19:46:33 +01:00

@jeremystretch commented on GitHub (Feb 18, 2023):

I did some digging into this today, and unfortunately it doesn't seem as straightforward to implement as I had hoped. There are two template renderers that might interest us: DjangoTemplates and TemplatesSetting.

DjangoTemplates is the default renderer, and loads templates from two places:

The built-in Django templates path
A templates/ path within each installed app

This seems suboptimal for us, as we store most templates under the project-level templates/ directory (rather than inside each app), and I much prefer this approach as it makes organizing common templates and searching for template code much easier.

The TemplatesSetting renderer loads templates per the TEMPLATES setting used to load non-form templates. This would work for us, except that it excludes the built-in Django path entirely, so forms and widgets that rely on these stock templates break. We could add the Django forms template path to TEMPLATES, but this seems a bit messy.

Further, it's disconcerting that there are two base renderer attributes that were both introduced and deprecated in Django 4.1.

Given the unexpected challenges in implementing the proposed change, I'm going to bump this from v3.5 and leave it open for discussion.

@jeremystretch commented on GitHub (Feb 18, 2023): I did some digging into this today, and unfortunately it doesn't seem as straightforward to implement as I had hoped. There are two template renderers that might interest us: [`DjangoTemplates`](https://docs.djangoproject.com/en/4.1/ref/forms/renderers/#djangotemplates) and [`TemplatesSetting`](https://docs.djangoproject.com/en/4.1/ref/forms/renderers/#templatessetting). `DjangoTemplates` is the default renderer, and loads templates from two places: * The built-in Django templates path * A `templates/` path within each installed app This seems suboptimal for us, as we store most templates under the project-level `templates/` directory (rather than inside each app), and I much prefer this approach as it makes organizing common templates and searching for template code much easier. The `TemplatesSetting` renderer loads templates per the `TEMPLATES` setting used to load non-form templates. This would work for us, except that it excludes the built-in Django path entirely, so forms and widgets that rely on these stock templates break. We could add the Django forms template path to `TEMPLATES`, but this seems a bit messy. Further, it's disconcerting that there are two [base renderer](https://docs.djangoproject.com/en/4.1/ref/forms/renderers/#django.forms.renderers.BaseRenderer) attributes that were both introduced and deprecated in Django 4.1. Given the unexpected challenges in implementing the proposed change, I'm going to bump this from v3.5 and leave it open for discussion.

adam commented

2025-12-29 19:46:33 +01:00

@jeremystretch commented on GitHub (May 2, 2023):

Closing this as there's no real impetus for its implementation. Happy to revisit this in the future, perhaps as part of the UI overhaul for v4.0.

@jeremystretch commented on GitHub (May 2, 2023): Closing this as there's no real impetus for its implementation. Happy to revisit this in the future, perhaps as part of the UI overhaul for v4.0.

adam referenced this issue

2025-12-29 22:26:39 +01:00

[PR #7969] [CLOSED] Fix #6905: Assign existing prefix to VLAN from VLAN view #13305

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#6905