Change Details

In T193392 an attempt to align the prefix keyword with common practices used by cirrus keyword was made by attempting to warn the user that the namespace requested is not compatible with the list of selected namespace. This approach caused many custom search boxes (using the InputBox extension) to fail. Overriding the list of namespaces is not a sane design and will cause issues later on when we'll improve the search query syntax. I suggest another approach to make this keyword better fit future development: - at parse time the prefix keyword will inform the parser that it needs additional namespace to function properly - the parser will then decide what to do with this -- if the namespace was already requested: noop -- if the namespace was not requested: add it to the list requested namespaces Since this behavior is unique to the prefix keyword I suggest adding a special key value that the parser can inspect when calling `KeywordFeature::parseValue` rather than promoting this behavior at the API level. Impact: - existing queries should work as before - will allow to support OR between this keyword and other keywords (not possible if the namespace is overridden)

In T193392 an attempt to align the prefix keyword with common practices used by cirrus keyword was made by emitting warning to the user stating that the namespace requested is not compatible with the list of selected namespace. This approach caused many custom search boxes (using the InputBox extension) to fail. Overriding the list of namespaces is not a sane design and will cause issues later on when we'll improve the search query syntax. I suggest another approach to make this keyword better fit future development: - at parse time the prefix keyword will inform the parser that it needs additional namespace to function properly - the parser will then decide what to do with this -- if the namespace was already requested: noop -- if the namespace was not requested: add it to the list requested namespaces Since this behavior is unique to the prefix keyword I suggest adding a special key value that the parser can inspect when calling `KeywordFeature::parseValue` rather than promoting this behavior at the API level. Impact: - existing queries should work as before - will allow to support OR between this keyword and other keywords (not possible if the namespace is overridden)

In T193392 an attempt to align the prefix keyword with common practices used by cirrus keyword was made by attempemitting to warnning to the user stating that the namespace requested is not compatible with the list of selected namespace. This approach caused many custom search boxes (using the InputBox extension) to fail. Overriding the list of namespaces is not a sane design and will cause issues later on when we'll improve the search query syntax. I suggest another approach to make this keyword better fit future development: - at parse time the prefix keyword will inform the parser that it needs additional namespace to function properly - the parser will then decide what to do with this -- if the namespace was already requested: noop -- if the namespace was not requested: add it to the list requested namespaces Since this behavior is unique to the prefix keyword I suggest adding a special key value that the parser can inspect when calling `KeywordFeature::parseValue` rather than promoting this behavior at the API level. Impact: - existing queries should work as before - will allow to support OR between this keyword and other keywords (not possible if the namespace is overridden)