Convert device/VM component templates to tables

[jeremystretch]

Proposed Changes

When viewing a device, its associated components (console ports, power outlets, interfaces, etc.) are displayed in tables, however each row is rendered using a static template (e.g. dcim/inc/interface.html). The same goes for virtual machine interfaces. This issue proposes replacing these static templates with Table objects, similar to how the global component lists are rendered.

Justification

This change would have several benefits:

• Reduce template footprint
• Enable ordering components by field
• Enable toggling the display of certain fields (user preference)
• Potentially support pagination

[DanSheps]

Would this be a good time to look at something like datatables for this?

[jeremystretch]

I opened this primarily as a reminder to myself, but recall that #4193 was opened a while back and as you mention datatables was suggested. However, that was before we introduced the ability to toggle and order table columns. I'm not necessarily opposed to implementing datatables, but I'd prefer to avoid the dependency and UI overhead if we can. I also don't want to risk putting too much effort into a frontend component that will potentially be replaced in a v3.0 world anyway.

It should be fairly straightforward to convert the existing templates to Table objects. Let me dig into it a bit more and if it seems to be a reasonable amount of effort for a few quick wins (enumerated above) I'd be happy with that for now.

[whitej6]

@jeremystretch please assign to me

[jeremystretch]

@whitej6 Are you sure? This is going to be fairly involved: each of the device component tables employed under the component list views (e.g. dcim.tables.ConsolePortTable) needs to be extended so that it can be used under individual devices views as well, to replace the inclusion templates. It will also be necessary to convert the display of IP addresses attached to interfaces to table columns (rather than subtables as they currently exist). These changes need to be made while ensuring none of the existing functionality is lost.

As we're getting ready to make the jump to v2.9, these changes will need to be made against the develop-2.9 branch. However, as it should be a fairly transparent opaque change to the user, it doesn't necessarily need to be done in time for the v2.9.0 release.

[jeremystretch]

@whitej6 Can you share what progress you've made on this?