Our filtering works in a similar way to how searching does but on a per model basis. A user can simply use the filtering bar in order to remove unwanted instances of the model. At a high level, the filter bar allows the user to send a request to the server, which the server then processes. All of the attributes of the model are filtered and pre-processed to be sent back to the client which displays the filter results in the same way that other models are displayed with no client side logic needed to display the results.

The actual technical details are somewhat a mix between searching and sorting. The request is sent back to display the current page but filtered so that certain strings are not present in the final result. This is routed to the overview() method which handles the incoming request, parses all of the parameters, and then executes the query. The query is always in the same form for every request, and is simply changed by the parameters. If the parameters are not included (for example a filter without a sort) then the parameters are set to a sane default (sort by 'name' in this case) and the query is executed like normal. Therefore, the query is executed by filtering out anything that doesn't match the filter, and then inserted back into the Jinja2 template and returned. The client does not even have to know that the data was filtered, all it sees is the results and displays the results in an organized manner.

We chose to keep filtering on the backend for the same reason we decided to keep searching and sorting on the back end: we already have several library functions in the back end that makes it easier and faster to develop these methods in the backend. If we were to develop code to handle these requests in the front end, we would simply be translating the code from python to javascript and introducing several more errors along the way.

results matching ""

    No results matching ""