Refactor search code

[ffont]

Freesound is awesome but the code that performs search queries has been getting more and more complex over time. A couple of years ago we did some refactoring which involved how we communicate with the search engine backend (i.e. how we communicate with SOLR), but the code related to search views (including API) ins structured in a very complicated way and it is becoming harder to add new features. It would be good to give some love to that and refactor so adding new options to the search page becomes easier (and thus can be done also as part of our research activities maybe?).

I started doing a refactoring some time ago but the whole thing was becoming really complex (see this branch, which might have diverted too much from master). The main idea was to use a Django form to manage the search input parameters, but this had its own set of issues.

I'm not sure how we should approach the refactor, but here are some notes/ideas to consider:

• We should further separate user input from backend actions. For example, right now we use a filter syntax which we pass to the backend mostly "as is". We should define our own syntax for filters independently of the filtering syntax of the search engine backend, and then the backend should convert filters to its specific format. Note that to be backwards compatible we should adopt the SOLR dismax query parser syntax, but using a parser in the middle it will allow us to handle filter processing in a much nicer way.
• We should find a way to programatically define all the options of the search form (and advanced search form) and pass them to the backend engine so they can be translated to actual query filters. We probably need to add more arguments to the definition of search engine backends, but we should do it in a way which it is well documented how to add new search options.
• Currently the search page code uses some JS stuff which should not necessarily be there. This sometimes complicates things. Make sure that we implement search page in the simplest possible way.
• Ideally we should have some structure similar to a django form (maybe a django form?) which stores all the options of a query (and also knows about all possible options) and this can be used to generate the web forms, the links to previous/next pages, etc. I tried directly using a django form but it was quite complicated.