Proof-of-concept: Introduce HTMX-based replacement for QuickSelect component in Maintenance tool #2883
Conversation
There was a problem hiding this comment.
There ought to be a naming convention for html templates that do not contain {% extends ..%}, that is: html fragments changing parts of a page, not an entire page.
Some possible naming conventions:
- Prefix with
_(single underline) - End with
-frag.html, not.html - End with
-partial.html, not.html
| @@ -363,6 +364,27 @@ def edit(request, task_id=None, start_time=None, **_): | |||
| ) | |||
|
|
|||
|
|
|||
| def component_search(request): | |||
There was a problem hiding this comment.
Prefix with @require_http_methods(["POST"])
python/nav/web/maintenance/urls.py
Outdated
| @@ -32,6 +32,7 @@ | |||
| re_path(r'^active/$', views.active, name='maintenance-active'), | |||
| re_path(r'^planned/$', views.planned, name='maintenance-planned'), | |||
| re_path(r'^historic/$', views.historic, name='maintenance-historic'), | |||
| re_path(r'^search/$', views.component_search, name='maintenance-crazy-shit'), | |||
There was a problem hiding this comment.
Why stick with re_path? path is easier to read.
There was a problem hiding this comment.
I could ask you the same. I used the same pattern as the surrounding lines. They were all last modified by you as part of some Django upgrade, I believe :)
Since NAV never started out as a Django project, there has never been an explicit agreed-upon convention for this in NAV. I suspect a lot of this is pretty unused in NAV to distinguish fragments today, except for one subsystem: ipdevinfo uses the |
As mentioned in code review.
Add -frag moniker to partial templates
I don't have any particularly strong opinion on this one. But here are my thoughts:
The differences are minuscule IMO and are more a case of personal preferences. Unless we discover some more "technical" reasons to choose one over the other.. |
|
Discovered another naming variant used in NAV:
|
This is related to both #2639 and #2251 .
It's a very crude start to a PoC that can potentially replace the b0rked QuickSelect component used in the Maintenance tool. The QuickSelect component is also used by the IP Device History tool, and could be replaced also there once complete.
Quick explanation, for now: The QuickSelect component is pre-populated with all netboxes, locations, rooms, services, etc. from NAV, and is consequently output into the resulting HTML of the maintenance task edit form. From that HTML, QuickSelect's JavaScript counterpart allows the user to filter form values from this potentially giant list of stuff. This is exactly why the page load times can grow very long in big NAV installs, as mentioned in #2251. It will grow even bigger if we add an option to put interfaces on maintenance, which is a feature that has been suggested to us.
This PR intends to demonstrate how to use HTMX to dynamically look up maintenance components by having the backend do the searching and return fully formed HTML with the results. The potential downside to this approach is that there will be no initial scrollable list of all components: The user must enter at least a single letter search query to see any selectable components. This might still be preferable to loading "everything" from the database into an HTML fragment (this is equivalent to the API strategy that refuses to return all the millions of ARP entries when no arguments are given to the endpoint)