Restructure device component templates #3340

New Issue

adam · 2025-12-29T18:27:57+01:00

adam commented

2025-12-29 18:27:57 +01:00

Originally created by @jeremystretch on GitHub (Feb 18, 2020).

Proposed Changes

We need to devise a cleaner method of displaying components on the device view. This is needed both to accommodate the display of additional attributes and other data, and to ensure long-term maintainability.

Justification

The current implementation employs an {% include %} block inside a for loop to instantiate a template, rendering one or two HTML tables rows per object. Some of these templates, particularly the interface template, has grown quite complex. There are several aspects to consider as part of this initiative:

Can we leverage different DOM elements in place of tables? (This may require upgrading to Bootstrap 4.)
Can we enable column-based ordering of items, like what django-tables2 provides for normal object lists?
Should we look into populating some data dynamically via the API to improve performance? This would be particularly beneficial when displaying interfaces: There is no need to query IP address or VLAN information, for instance, if the user has opted not to display that information.

Originally created by @jeremystretch on GitHub (Feb 18, 2020). ### Proposed Changes We need to devise a cleaner method of displaying components on the device view. This is needed both to accommodate the display of additional attributes and other data, and to ensure long-term maintainability. ### Justification The current implementation employs an `{% include %}` block inside a `for` loop to instantiate a template, rendering one or two HTML tables rows per object. Some of these templates, particularly the interface template, has grown quite complex. There are several aspects to consider as part of this initiative: * Can we leverage different DOM elements in place of tables? (This may require upgrading to Bootstrap 4.) * Can we enable column-based ordering of items, like what django-tables2 provides for normal object lists? * Should we look into populating some data dynamically via the API to improve performance? This would be particularly beneficial when displaying interfaces: There is no need to query IP address or VLAN information, for instance, if the user has opted not to display that information.

adam added the type: housekeeping label 2025-12-29 18:27:57 +01:00

adam closed this issue

2025-12-29 18:27:57 +01:00

adam commented

2025-12-29 18:27:58 +01:00

@tyler-8 commented on GitHub (Feb 18, 2020):

The datatables project could be a possibility for helping with item 2 & 3. It has Bootstrap support built-in, and handles API pagination if setup correctly (there's a DRF plugin that does it automatically).

@tyler-8 commented on GitHub (Feb 18, 2020): The [datatables](https://datatables.net/) project could be a possibility for helping with item 2 & 3. It has Bootstrap support built-in, and handles API pagination if setup correctly (there's a [DRF plugin](https://github.com/izimobil/django-rest-framework-datatables) that does it automatically).

adam commented

2025-12-29 18:27:59 +01:00

@DanSheps commented on GitHub (Feb 18, 2020):

FYI, Bootstrap 4 does have quite a big change to the nav menu structure, but I do think going to BS4 would be a move in the right direction.

Never used datatables, however I am a big fan of bootstrap 4. Does datatables support BS4 or does it need to sick with BS3?

@DanSheps commented on GitHub (Feb 18, 2020): FYI, Bootstrap 4 does have quite a big change to the nav menu structure, but I do think going to BS4 would be a move in the right direction. Never used datatables, however I am a big fan of bootstrap 4. Does datatables support BS4 or does it need to sick with BS3?

adam commented

2025-12-29 18:28:00 +01:00

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

I've come across datatables before but haven't looked too closely at it. The biggest likely problem is that we're not dealing with simple single-row-per-object tables: Multiple rows of objects are required per object to display things like tags, IP addresses, and VLANs. This is why I'd like to move away from tables if possible in favor of something more flexible.

@jeremystretch commented on GitHub (Feb 18, 2020): I've come across datatables before but haven't looked too closely at it. The biggest likely problem is that we're not dealing with simple single-row-per-object tables: Multiple rows of objects are required per object to display things like tags, IP addresses, and VLANs. This is why I'd like to move away from tables if possible in favor of something more flexible.

adam commented

2025-12-29 18:28:00 +01:00

@tyler-8 commented on GitHub (Feb 18, 2020):

Bootstrap 4 does have quite a big change to the nav menu structure, but I do think going to BS4 would be a move in the right direction.

Never used datatables, however I am a big fan of bootstrap 4. Does datatables support BS4 or does it need to sick with BS3?

Bootstrap 3 to 4 requires a fair amount of work, though I agree, it's the right move at some point. (official docs | summarized guide)

AFAIK, datatables integrates with BS4 fine: https://datatables.net/examples/styling/bootstrap4

The biggest likely problem is that we're not dealing with simple single-row-per-object tables...

In that case datatables wouldn't be that helpful. Granted, I've only given it about 2 minutes of thought but I worry that too much data is going to be crammed in to one page. An interface listing in tabular format gives the cleanest summarized view of most of the data. Perhaps use of tooltips or dynamically expanding elements to get drill-down info (like list of VLANs tagged) would be one alternative to scrapping tables entirely.

if the user has opted not to display that information

Smells like a case for GraphQL APIs. No but really - if we're treading in to the world of having users choose which complex data structures they want to see (beyond simple filtering), you don't want to pull all the data and then parse out pieces and build new serializers/views every time a new API output is decided upon. You want the user to retrieve only the data they want and then display it. Luckily, on the API tooling side, there is already an excellent tool for doing that for Django. This is all out of scope for this issue of course, but seems like it could be related.

@tyler-8 commented on GitHub (Feb 18, 2020): > Bootstrap 4 does have quite a big change to the nav menu structure, but I do think going to BS4 would be a move in the right direction. > Never used datatables, however I am a big fan of bootstrap 4. Does datatables support BS4 or does it need to sick with BS3? Bootstrap 3 to 4 requires a fair amount of work, though I agree, it's the right move at some point. ([official docs](https://getbootstrap.com/docs/4.4/migration/) | [summarized guide](https://medium.com/@lukaszholeczek/migration-from-bootstrap-3-to-bootstrap-4-4ec63a1dd8b1)) AFAIK, `datatables` integrates with BS4 fine: https://datatables.net/examples/styling/bootstrap4 > The biggest likely problem is that we're not dealing with simple single-row-per-object tables... In that case `datatables` wouldn't be that helpful. Granted, I've only given it about 2 minutes of thought but I worry that too much data is going to be crammed in to one page. An interface listing in tabular format gives the cleanest summarized view of most of the data. Perhaps use of tooltips or dynamically expanding elements to get drill-down info (like list of VLANs tagged) would be one alternative to scrapping tables entirely. > if the user has opted not to display that information Smells like a case for [GraphQL](https://graphql.org/) APIs. No but really - if we're treading in to the world of having users choose which complex data structures they want to see (beyond simple filtering), you don't want to pull all the data and then parse out pieces and build new serializers/views every time a new API output is decided upon. You want the user to retrieve only the data they want and then display it. Luckily, on the API tooling side, there is already an [excellent tool](https://github.com/graphql-python/graphene-django) for doing that for Django. This is all out of scope for this issue of course, but seems like it could be related.

adam commented

2025-12-29 18:28:00 +01:00

@minitriga commented on GitHub (Feb 19, 2020):

In terms of showing more data within a row. Datatables supports child rows, we used this on a custom IPAM/DCIM/Ticketing system when I worked at Cisco. This helped us show the different relationships between objects easier while keeping the table pretty clutter-free.

https://datatables.net/examples/api/row_details.html

@minitriga commented on GitHub (Feb 19, 2020): In terms of showing more data within a row. Datatables supports child rows, we used this on a custom IPAM/DCIM/Ticketing system when I worked at Cisco. This helped us show the different relationships between objects easier while keeping the table pretty clutter-free. https://datatables.net/examples/api/row_details.html

adam commented

2025-12-29 18:28:01 +01:00

@DanSheps commented on GitHub (Feb 19, 2020):

Thanks @minitriga my look is that looks like exactly what we need

@DanSheps commented on GitHub (Feb 19, 2020): Thanks @minitriga my look is that looks like exactly what we need

adam commented

2025-12-29 18:28:01 +01:00

@Arkasha99 commented on GitHub (Feb 21, 2020):

What about using split.js? We don't need those "show IP" or "show VLANs" buttons then, we just click on interface and open split view window, showing all the info about particular interface like in jira kanban. We can also use datatables filtering inside this window.
https://split.js.org/

@Arkasha99 commented on GitHub (Feb 21, 2020): What about using split.js? We don't need those "show IP" or "show VLANs" buttons then, we just click on interface and open split view window, showing all the info about particular interface like in jira kanban. We can also use datatables filtering inside this window. https://split.js.org/

adam commented

2025-12-29 18:28:02 +01:00

@DanSheps commented on GitHub (Feb 27, 2020):

So, looking into datatables a bit, it does look like it is looking for some specific variable returned from a rest API if the API is to be queried each time.

@DanSheps commented on GitHub (Feb 27, 2020): So, looking into datatables a bit, it does look like it is looking for some specific variable returned from a rest API if the API is to be queried each time.

adam commented

2025-12-29 18:28:02 +01:00

@minitriga commented on GitHub (Feb 27, 2020):

Indeed when you click the dropdown button perform an API call to get the data you would like it doesn't require anything specific through. Not sure if you would want to prepopulate the page with all data required for the table or do API calls for each row child.

https://jsfiddle.net/c5yxjz0f/3

I altered a jsfiddle project to do an API call to a public API and present the data if succeeded but not sure if this would work for NetBox.

@minitriga commented on GitHub (Feb 27, 2020): Indeed when you click the dropdown button perform an API call to get the data you would like it doesn't require anything specific through. Not sure if you would want to prepopulate the page with all data required for the table or do API calls for each row child. https://jsfiddle.net/c5yxjz0f/3 I altered a jsfiddle project to do an API call to a public API and present the data if succeeded but not sure if this would work for NetBox.

adam commented

2025-12-29 18:28:02 +01:00

@tyler-8 commented on GitHub (Feb 27, 2020):

So, looking into datatables a bit, it does look like it is looking for some specific variable returned from a rest API if the API is to be queried each time.

Out of the box it has a specific structure it expects the data to be in, however it is customizable with varying degrees of complexity depending on how you want to shape the data.

@tyler-8 commented on GitHub (Feb 27, 2020): > So, looking into datatables a bit, it does look like it is looking for some specific variable returned from a rest API if the API is to be queried each time. Out of the box it has a specific structure it expects the data to be in, however it is customizable with varying degrees of complexity depending on how you want to shape the data.

adam commented

2025-12-29 18:28:02 +01:00

@DanSheps commented on GitHub (Mar 10, 2020):

I finally have had a chance to circle back around to this. @minitriga that only works if you are loading all of the data into ajax at once. Unfortunately, we would be using server side processing because loading all data will most likely result in timeout issues for people.

Server side processing expects data to be returned in a specific format, so we would need to alter our serializers based on whether or not we are using datatables. It is expecting the draw, recordsTotal and recordsFiltered fields, and we would need to rename our "results" key to "data". I am not opposed to going in this route in the future, but it looks like it won't be as simple and this would need to be done in a major release. Our current serializers are just not configured to handle what datatables would require and it would be a major deviation from our current API.

We might be able to re-map it but we would still need to find out how many records we have total, and we would need to handle the "draw" parameter.

@DanSheps commented on GitHub (Mar 10, 2020): I finally have had a chance to circle back around to this. @minitriga that only works if you are loading all of the data into ajax at once. Unfortunately, we would be using server side processing because loading all data will most likely result in timeout issues for people. Server side processing expects data to be returned in a specific format, so we would need to alter our serializers based on whether or not we are using datatables. It is expecting the draw, recordsTotal and recordsFiltered fields, and we would need to rename our "results" key to "data". I am not opposed to going in this route in the future, but it looks like it won't be as simple and this would need to be done in a major release. Our current serializers are just not configured to handle what datatables would require and it would be a major deviation from our current API. We might be able to re-map it but we would still need to find out how many records we have total, and we would need to handle the "draw" parameter.

adam commented

2025-12-29 18:28:03 +01:00

@jeremystretch commented on GitHub (Jul 24, 2020):

Closing this out in favor of #4786 now that tables are configurable per-user.

@jeremystretch commented on GitHub (Jul 24, 2020): Closing this out in favor of #4786 now that tables are configurable per-user.

adam commented

2025-12-29 18:28:03 +01:00

@jeremystretch commented on GitHub (Jul 24, 2020):

Closing this out in favor of #4786 now that tables are configurable per-user.

@jeremystretch commented on GitHub (Jul 24, 2020): Closing this out in favor of #4786 now that tables are configurable per-user.

adam referenced this issue

2025-12-29 22:22:33 +01:00

[PR #3613] [MERGED] modified front port connection type list #12598

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#3340