8430b67d55
- document the methods in an extension guide - add integration test to make sure that all tested OSes work as intended Signed-off-by: Sebastian Malton <sebastian@malton.name>
2.1 KiB
Lens Protocol Handlers
Lens has a file association with the lens:// protocol.
This means that Lens can be opened by external programs by providing a link that has lens as its protocol.
Lens provides a routing mechanism that extensions can use to register custom handlers.
Registering A Protocol Handler
The method onProtocolRequest exists both on LensMainExtension and on LensRendererExtension.
This is how, as an extension developer, you can register handlers for your extension.
The pathSchema argument must comply with the path-to-regexp package's compileToRegex function.
Once you have registered a handler it will be called when a user opens a link on their computer.
The routing mechanism for extensions is quite straight forward.
For example consider an extension example-extension which is published by the @mirantis org.
If it were to register a handler with "/display/:type" as its corresponding link then we would match the following URI like this:
Once matched, the handler would be called with the following argument (note both "search" and "pathname" will always be defined):
{
"search": {
"text": "Hello"
},
"pathname": {
"type": "notification"
}
}
As the diagram above shows, the search (or query) params are not considered as part of the handler resolution.
If multiple pathSchema's match a given URI then the most specific handler will be called.
For example consider the following pathSchema's:
"/""/display""/display/:type""/show/:id"
The URI sub-path "/display" would be routed to #2 since it is an exact match.
On the other hand, the subpath "/display/notification" would be routed to #3.
The URI is routed to the most specific matching pathSchema.
This way the "/" (root) pathSchema acts as a sort of catch all or default route if no other route matches.