-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closes: #9583 - Add column specific search field to tables #15073
base: feature
Are you sure you want to change the base?
Closes: #9583 - Add column specific search field to tables #15073
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is mostly there
@@ -5,7 +5,7 @@ | |||
<div class="col-auto d-print-none"> | |||
<div class="input-group input-group-flat me-2 quicksearch"> | |||
<input type="search" results="5" name="q" id="quicksearch" class="form-control px-2 py-1" placeholder="Quick search" | |||
hx-get="{{ request.full_path }}" hx-target="#object_list" hx-trigger="keyup changed delay:500ms, search" /> | |||
hx-get="" hx-target="#object_list" hx-trigger="keyup changed delay:500ms, search" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed full path, as this will allow taking into account filters on the form (to facilitate pushing of the filters from the column as well).
Should not impact functionality
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should not impact functionality
Do we know this for sure? IIRC we specify the full path for a reason, I just can't recall why.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my testing, I haven't found any issues with it.
…field_to_tables' into 9583-add_column_specific_search_field_to_tables
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…ction for column filters
@@ -5,7 +5,7 @@ | |||
<div class="col-auto d-print-none"> | |||
<div class="input-group input-group-flat me-2 quicksearch"> | |||
<input type="search" results="5" name="q" id="quicksearch" class="form-control px-2 py-1" placeholder="Quick search" | |||
hx-get="{{ request.full_path }}" hx-target="#object_list" hx-trigger="keyup changed delay:500ms, search" /> | |||
hx-get="" hx-target="#object_list" hx-trigger="keyup changed delay:500ms, search" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should not impact functionality
Do we know this for sure? IIRC we specify the full path for a reason, I just can't recall why.
field.field.widget.attrs.update({ | ||
'id': f'table_filter_id_{field.name}', | ||
'hx-get': url if url else '#', | ||
'hx-push-url': "true", | ||
'hx-target': '#object_list', | ||
'hx-trigger': 'hidden.bs.dropdown from:closest .dropdown' | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this approach is tenable: We're using the same form field for both the column and the regular filter form (behind the second tab). Setting HTMX attributes on a non-HTMX form field should be avoided, and overriding its ID may cause problems. IMO we should try to identify a cleaner approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have went ahead and made a possible modification to this.
In bulk views, I initialize two copies of the form:
- A copy of the form for the filtering tab
- A copy of the form for the table column filtering
Since this render_table_filter_field tag is only used by the table coumn filtering logic, this shouldn't be a problem anymore.
Let me know if this approach is a more "safer" one while allowing for some code re-use. I can go a little deeper and perhaps modify all filtersets to add a "column filter" tuple to allow a more clean approach to limiting the columns as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT this should work fine, but do we need a full form instance for the columns? It might suffice to make a copy of the relevant fields from the filter form and attach them to their respective columns.
Though with either approach, I feel like we're missing a step. The current implementation depends on the column name and the field name matching (form_field=table.filterset_form|get_filter_field:column.name
). This should work ~95% of the time but inevitably we're going to find exceptions. I'd like to see if we can devise a more robust approach, short of duplicating the field definitions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT this should work fine, but do we need a full form instance for the columns? It might suffice to make a copy of the relevant fields from the filter form and attach them to their respective columns.
Instead of initializing the form right away, we could copy the form definition and then remove fields that not present on the table before intitialization. This feels like excess code for very little gain however
Though with either approach, I feel like we're missing a step. The current implementation depends on the column name and the field name matching (
form_field=table.filterset_form|get_filter_field:column.name
). This should work ~95% of the time but inevitably we're going to find exceptions. I'd like to see if we can devise a more robust approach, short of duplicating the field definitions.
I think we should handle this on a case-by-case. The only other option would be looking at the table and building a completely new form class dynamically based on the table field types, however we then would likely lose all the custom filtering unless we tie it with the existing filter form somehow.
Another concern: There's no way to quickly discern when a column filter has been applied. |
This PR has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further action is taken. |
This PR has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further action is taken. |
This PR has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further action is taken. |
This PR has been automatically closed due to lack of activity. |
This PR has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further action is taken. |
This PR has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further action is taken. |
This PR has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further action is taken. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry it's taken so long to revisit this PR. We're working now on cleaning up the PR backlog.
if self.filterset_form and table.filterset_form: | ||
filterset_form = self.filterset_form(request.GET) | ||
table.filterset_form = table.filterset_form(request.GET) | ||
elif self.filterset_form and not table.filterset_form: | ||
filterset_form = self.filterset_form(request.GET) | ||
table.filterset_form = self.filterset_form(request.GET) | ||
elif not self.filterset_form and table.filterset_form: | ||
filterset_form = None | ||
table.filterset_form = table.filterset_form(request.GET) | ||
else: | ||
filterset_form = None | ||
table.filterset_form = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we ditch the association of a filterset form on the table directly, and just use the one associated with the view? That would make things a lot cleaner.
# Check for a table form column map attribute and use that to map form fields if set | ||
if hasattr(form, '_table_form_column_map') and form._table_form_column_map.get(fieldname): | ||
return getfield(form, form._table_form_column_map.get(fieldname)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is _table_form_column_map
getting set? If it's not yet needed, let's ditch it for now.
filter_chits = render_to_string('inc/applied_filters_pane.html', { | ||
'model': model, | ||
'filter_form': filterset_form, | ||
}, request) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO all rendering logic should go within the table itself, and should be consistent for both natural and HTMX requests.
{% if table.filterset_form %} | ||
{% include 'inc/table_header_filter_dropdown.html' with form_field=table.filterset_form|get_filter_field:column.name %} | ||
{% endif %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we associate filter field names directly with their corresponding table columns? That would simplify things a bit.
Closes: #9583 - Add column specific search field to tables
The plan is to use the existing filterset to generate form fields on the table column headers to allow for inline-filtering using HTMX requests
Progress
Todo
Add input fields for "name"Not needed - Quick search is suitable for thisFix filter float (Move before field name perhaps)DoneAdd show/hide filter (Optional)Outside of scope