This sub-class of Modifier, TextSearchModifier, is the only one I have created so far.
Each Modifier class takes two arguments when initialised, template and search_key.
Even if the Modifier doesn't do anything different when it comes to querying, it might still want to use a different template, which is now also determined by the Modifier.
The templates themselves meanwhile are in a templates directory, and I have provided a django_easyfilters/text_search.html for the text search.
The other important thing a Modifier has is its own apply_filter() method.
Now when FilterSet.apply_filters() is looping over the filters, it will also call the apply_filter() methods in the Modifier, which might do something different, if required (as the one in TextSearchModifier does).
The TextSearchModifier() method makes use of the search_key. If it's not provided, it will just default to filter.field_obj.name. That's only useful if we want to match the exact text on that particular field, so we can also do for example:
I've commented out the second one; I'm sure it used to work before with multiple ones, but now, nothing is returned even if the second box is left blank. The URL might look like: ?searchbtn=Search&hosted_by=Public&title=, and even though the searchvariable within the TextSearchModifier.apply_filter() in that case might be null, it still seems to affect the search.
Text searches destroy existing filters
You can do a text search followed by a date filter and that will work, but a text search after a date filter will destroy the date filter. That seems really hard to solve. I have been trying to work out a way to get the existing filters into the context so hidden <input> buttons can restore them into the URL that's created.
I think that fuller view functionality in django-easyfilters will be required for that.
Text search boxes don't retain their text
Again, I think that to do this in django-easyfilters will require a view class or function in it, so it can manipulate what it puts into the templates.
I am not at all sure of the general approach. However it seemed important to solve this problem not by simply creating new Filter subclasses and types, because the needs for different templates/behaviours could still be part of existing Filters. The needs seem to be orthogonal to each other, hence the creation of the Modifier class to express that.