lukavdplas
commented
1 year ago some of which (e.g., size, position) might also be used as field names on corpora
I was thinking of making an issue of this. It seems like a bug waiting to happen that some field names are essentially 'off limits' since they are the names of route parameters and would be interpreted as filters. We should either include some validation that rejects corpus definitions using those names, or construct parameters differently.
Anyway, using ngramOptions=... seems like a good idea! The ngram is the most complicated and that one already has a function to convert parameters to/from a string. (Though you'll have to change the join character, I think it's / right now.)
Currently, ngrams options add 6 query parameters in the route, some of which (e.g., size, position) might also be used as field names on corpora, in which case they'd clash with associated filters. Also, the route becomes very long that way. It might be better to reorganize the visualization options such that the query parameter for ngram becomes
?ngramOptions=s:2,p:any...This means we'll need to include some functions to get / set the visualization options correctly from and to the route.