Change Details

InitialSearchContext would be simple interface containing a subset of the information stored in the SearchContext: - entry point: (basically the method used to enter search: fulltext, prefix, nearmatch, ...) - the list of namespaces - the profile context - perhaps: limitSearchToLocalWiki (a boolean indicating that commons should not be searched) The InitialSearchContext will be set on every search entry point and will be until the end of the parsing process. A hook `CirrusSearchInitialSearchContextCreated` will be created to that extension can interfere the InitialSearchContext: - wikibase will be able to use this to switch to its profile context (assuming the list of namespace suits its need) Some keyword will implement a dedicated interface like 'InitialSearchContextKeyword', they will be able to change the list of namespaces, call setLimitSearchToLocalWiki This will eventually allow to remove the hook `CirrusSearchFulltextQueryBuilder`, by controlling the profile context early this should no longer be needed. This is also an attempt to split the SearchContext into small pieces, but the approach will just be a new interface that the current SearchContext will implement.

InitialSearchContext would be simple interface containing a subset of the information stored in the SearchContext: - entry point: (basically the method used to enter search: fulltext, prefix, nearmatch, ...) - the list of namespaces - the profile context - perhaps: limitSearchToLocalWiki (a boolean indicating that commons should not be searched) The InitialSearchContext will be set on every search entry point and will be until the end of the parsing process. A hook `CirrusSearchInitialSearchContextCreated` could be created to that extension can interfere with the InitialSearchContext: A hook `CirrusSearchQueryParseEnd` could be created so that extension can interfere with the InitialSearchContext just before it becomes read-only. - wikibase will be able to use this to switch to its profile context (assuming the list of namespace and the parsed query suits its need) Some keyword will implement a dedicated interface like 'InitialSearchContextKeyword', they will be able to change the list of namespaces, call setLimitSearchToLocalWiki This will eventually allow to remove the hook `CirrusSearchFulltextQueryBuilder`, by controlling the profile context early this should no longer be needed. This is also an attempt to split the SearchContext into small pieces, but the first approach will just be a new interface that the current SearchContext will implement. We also need to handle situations where multiple components would like to switch the profile context for the same search entry point. Most of the time the list of requested namespaces will be the criteria used but what happens if 2 extensions request to override for the same set of ns?

InitialSearchContext would be simple interface containing a subset of the information stored in the SearchContext: - entry point: (basically the method used to enter search: fulltext, prefix, nearmatch, ...) - the list of namespaces - the profile context - perhaps: limitSearchToLocalWiki (a boolean indicating that commons should not be searched) The InitialSearchContext will be set on every search entry point and will be until the end of the parsing process. A hook `CirrusSearchInitialSearchContextCreated` willcould be created to that extension can interfere with the InitialSearchContext: A hook `CirrusSearchQueryParseEnd` could be created so that extension can interfere with the InitialSearchContext just before it becomes read-only. - wikibase will be able to use this to switch to its profile context (assuming the list of namespace and the parsed query suits its need) Some keyword will implement a dedicated interface like 'InitialSearchContextKeyword', they will be able to change the list of namespaces, call setLimitSearchToLocalWiki This will eventually allow to remove the hook `CirrusSearchFulltextQueryBuilder`, by controlling the profile context early this should no longer be needed. This is also an attempt to split the SearchContext into small pieces, but the first approach will just be a new interface that the current SearchContext will implement. We also need to handle situations where multiple components would like to switch the profile context for the same search entry point. Most of the time the list of requested namespaces will be the criteria used but what happens if 2 extensions request to override for the same set of ns?