Statu quo
GlobalSearch only returns navigable ResultLinks. There's no way to trigger an action directly from search, forcing users to navigate to a specific entity/list first even for actions that don't need that context (e.g. quick-create, account-level actions).
Proposal
Let a SearchResultSet hold commands alongside links, so both can be mixed within the same group:
class SearchResultSet
{
// existing: addResultLink(SharpLinkTo $link, string $label, ?string $detail = null): ResultLink
final public function addCommand(string $commandClass, ?string $detail = null): CommandResult
{
// ...
}
}
Devs register commands explicitly in searchFor(), per result set — nothing is added automatically. For example, quick-creation shortcuts would only show up if a dev chooses to expose them:
public function searchFor(array $terms): void
{
$this->addResultSet('Recipes')
->addCommand(CreateRecipeCommand::class)
// or maybe even a
->proposeQuickCreationForEntity(SomeEntity::class)
->addResultLink(...);
$this->addResultSet('Account')
->addCommand(CheckVATValidity::class)
->addCommand(ManageAccountCommand::class);
}
Open question: EntityCommand vs. a new GlobalCommand
Two options, both legitimate:
Reuse EntityCommand/existing commands: search just becomes another entry point to fire commands that already exist elsewhere (list, quick-create). Less new API surface, but these commands carry assumptions (instance selection, list query params) that don't apply outside a list context.
New GlobalCommand type: a lighter base class (extending the shared Command, without list-specific concerns) built specifically for context-free actions. Cleaner semantics, but a new concept to document and maintain.
It would also be nice if the searched value was inputed to the commands, it would allow use cases as: « I type an IP address in the search bar, it does not appear in my IPAdrressEntity results, so i can fire a command to look it up and add it. »
Worth deciding before implementation — possibly both are needed: GlobalCommand for genuinely global actions (account/app-level), and letting addCommand() also accept an EntityCommand for devs who want to surface an existing one through search.
Statu quo
GlobalSearch only returns navigable ResultLinks. There's no way to trigger an action directly from search, forcing users to navigate to a specific entity/list first even for actions that don't need that context (e.g. quick-create, account-level actions).
Proposal
Let a SearchResultSet hold commands alongside links, so both can be mixed within the same group:
Devs register commands explicitly in searchFor(), per result set — nothing is added automatically. For example, quick-creation shortcuts would only show up if a dev chooses to expose them:
Open question: EntityCommand vs. a new GlobalCommand
Two options, both legitimate:
Reuse EntityCommand/existing commands: search just becomes another entry point to fire commands that already exist elsewhere (list, quick-create). Less new API surface, but these commands carry assumptions (instance selection, list query params) that don't apply outside a list context.
New GlobalCommand type: a lighter base class (extending the shared Command, without list-specific concerns) built specifically for context-free actions. Cleaner semantics, but a new concept to document and maintain.
It would also be nice if the searched value was inputed to the commands, it would allow use cases as: « I type an IP address in the search bar, it does not appear in my IPAdrressEntity results, so i can fire a command to look it up and add it. »
Worth deciding before implementation — possibly both are needed: GlobalCommand for genuinely global actions (account/app-level), and letting addCommand() also accept an EntityCommand for devs who want to surface an existing one through search.