There are many changes needed that may be out of scope for a simple gadget. To illustrate, here is a description of the changes that would have to be done to the Gadget code when using POST instead of GET:
- Add code for changing the methods of the search forms.
- Find a mechanism for persisting the deepcat search parameters. See below for suggestions.
- Add code to convert search-related links to hidden form submissions. Without hidden form submission the links will run into the get limit again.
Persisting deepcat search parameters
To replace the generated "incategory" terms on the result page, the original search terms containing "deepcat:" terms must be persisted between the search page and the result page. Same for the errors from the AJAX calls. We have at least 2 options for persistence:
- Mixing GET and POST*: The Gadget code in substituteSearchRequest and addErrorMsgField would have to be rewritten to append GET parameters (deepCatSearch and deepCatError) to the search forms actions instead of appending fields. The WebRequest class in the Wiki code munges GET and POST together (POST overriding GET), so mixing data sources is not a problem.
Convert search-related links
The search-related links are the scope links at the top of the search results and the paging links at the bottom of the search results. They contain the full search term string which will be truncated when the link is clicked. My proposal to solve this:
Rewrite appendToSearchLinks and instead of just appending the deepCatSearch parameter to the href, create an onClick handler for the links that does the following steps:
- Create a hidden form element with a POST action
- Set the action of the form to the href of the link (minus the search param)
- Append the deepCatSearch parameter to the action.
- Add search field to the form. The value could come from the link, but to be sure it could also be set when newSearchTerms is generated.
- Cancel the click event and submit the hidden form instead.
We discussed in the meeting on 2015-08-05 that we should not start with this before we've tackled T108023.