@JeltevanBoheemen / @Meesch in case one of you picks up #1564 / #1563 / #1562 / #1561, my work in this branch may be of use.
Since there are several bugs surrounding the query comparison function, I started some work on refactoring it (instead of patching the specific errors). At present, query comparison is based on the ParamSync class, which is deprecated; this implements a ComparedQueries model that is based on StoreSync instead.
Notes for development
Currently (as in, on the main branch), the routes for compared queries always repeat the original query as a compared term. (See the linked issues for some examples of urls). As I describe in the issues, counting the original query as a "compared term" can invite unpredictable behaviour (e.g., what should happen if the user deletes that term from the comparison).
I also ran into the issue that routes will currently contain multiple compareTerm parameters (one for each term). However, the RouterStoreService does not support multiple query parameters with the same key. It should be possible to change this, but I did not (yet) do so.
Because of these two issues, the branch breaks the format for URLs; e.g. this URL:
(Note: comma-separation in the URL is safe here, since typing a comma in the input field will break up the query. So compared queries cannot contain commas.)
To do:
[ ] If I recall correctly, the ComparedQueries input was more or less done, but the interface with the visualisation is not. Visualisations don't reload when they should. Note that query comparison happens in the BarchartComponent and the WordSimilarityComponent.
[ ] Implement a solution to the breaking changes in the URL pattern. Either
Rework the ComparedQueries model so it uses the old pattern. Adjust the RouterStoreService to support this.
Write a (small) service to redirect old URLs. The logic for conversion is quite straightforward (and deterministic), so this may be preferable.
@JeltevanBoheemen / @Meesch in case one of you picks up #1564 / #1563 / #1562 / #1561, my work in this branch may be of use.
Since there are several bugs surrounding the query comparison function, I started some work on refactoring it (instead of patching the specific errors). At present, query comparison is based on the
ParamSyncclass, which is deprecated; this implements aComparedQueriesmodel that is based onStoreSyncinstead.Notes for development
Currently (as in, on the main branch), the routes for compared queries always repeat the original query as a compared term. (See the linked issues for some examples of urls). As I describe in the issues, counting the original query as a "compared term" can invite unpredictable behaviour (e.g., what should happen if the user deletes that term from the comparison).
I also ran into the issue that routes will currently contain multiple
compareTermparameters (one for each term). However, theRouterStoreServicedoes not support multiple query parameters with the same key. It should be possible to change this, but I did not (yet) do so.Because of these two issues, the branch breaks the format for URLs; e.g. this URL:
https://ianalyzer.hum.uu.nl/search/dbnl?query=woord&visualize=resultscount&visualizedField=periodical&compareTerm=woord&compareTerm=zin&compareTerm=paragraafwould now be formatted as
https://ianalyzer.hum.uu.nl/search/dbnl?query=woord&visualize=resultscount&visualizedField=periodical&compareTerms=zin,paragraaf(Note: comma-separation in the URL is safe here, since typing a comma in the input field will break up the query. So compared queries cannot contain commas.)
To do:
BarchartComponentand theWordSimilarityComponent.RouterStoreServiceto support this.