boyter
searching on multiple languages or repositories
Hi, while searching you can limit lang/repo to one, but when done you are not able to pick additional one.
Those are checkboxes (not radios) so I think intention was to allow multiselect on them.
Manually updating search query to http://localhost:8080/?q=test&repo=r1&repo=r2 will search on both r1 and r2 but not sort results on score, rather returning all r2 matches before r1 matches as I see.
after few more tests I think r1 and r2 results are sorted by score, sorry my mistake.
This is already in there actually. On any search page at the bottom of the filters is the section "Filter Options". If you uncheck "Apply Filters Instantly" then you will get the desired behaviour. This setting is saved in the browser storage too so it should persist so long as that is not cleared. You can then select multiple languages/repos and then click the apply button (which will become clickable as well).
This is the default setting because based on some hallway testing users were clicking and then waiting for something to happen. I had to prompt them to click apply, hence making the change.
Let me know if that works for you and we can hopefully close this.
Yep, now I can see it and with unchecked "Apply Filters Instantly" it works as charm.
I just wonder if you are not doing too much work there. In current state apply filters does many jobs instead of one:
- applies selected filter to the search results
- applies search results to available filters list
- recalculates counts of hits on each filter.
If you would resign from the second, the functionality could be simplified slightly.
What I mean: The filters would be populated initially on search phrase entry, and remain in this initial state. There is no point in trimming them after each filter is applied, and without this feature, it would be possible to maintain multi selection in live filters, so you could deprecate deferred filters at all. Search results are derived quickly enough to not need this option.
So that is something I had considered doing. The only catch is that it greatly increases the complexity of the search front-end because it suddenly needs to keep 2 states, the states of the filters and and the search results. Currently the state of the front-end is entirely driven by the results from any given search. IE a search is made and the UI updates.
What you are proposing also affects "deeplinks". Currently if say you perform a search like the following,
http://localhost:8080/?q=test&lan=Java&repo=server
And then send your colleague the link what they will see is exactly the same as you see. In order for the UI to reflect this it would need to perform 2 searches (or the backend but with the same result). One to get the state of the filters and one to get the state of search results with filters.
Those are the main reasons it is like it currently is. In short because I was being lazy and reusing the existing functionality.
That said what you are saying seems to be a better behaviour then what is currently happening and would allow.
TODO
Split the filter and search endpoints for search queries Filters should never have filters applied