While a Koha::Plugin has handy builtins for configuration in the form of store_data() and retrieve_data(), these are not easily accessible from the Mojolicious controllers that we configure in `api_routes()`. My use case specifically is allowing the plugin users to configure an API key in the Plugin (using `configure()`), and then using that API key in the Mojolicious controller. The way to accomplish this currently is manually instantiating the plugin in the controller and using that for the lookup as so: `Koha::Plugin::MyOrg::MyPlugin->new->retrieve_data(...)` This does not feel like a good solution since it's hard to say how Koha will react to us instantiating a Plugin multiple times without reading the code. It seems harmless for now, but there's no guarantee that it won't break something in the future. Ideally I'd see the alternative as something akin to https://metacpan.org/pod/Mojolicious::Controller#app method which currently that gives us a Koha::REST::V1 instance. I'd like to have a `plugin()` available in there as well, so that I could do a `$c->plugin->retrieve_data()` in my routes. Not sure how an implementation of that would look; perhaps there are better alternatives?
You can use: Koha::Plugins::Datas->find("Koha::Plugin::MyOrg::MyPlugin", $key)->plugin_value Not ideal but better than instantiating the plugin twice. A mojo helper would still require you to give your plugin name as one of the helper's arguments, right ? Not sure how we can avoid that.
Not sure how to do that specifically either, but it feels like it should be possible since Koha "knows" which Plugin caused this particular Controller to be instantiated/called. Not sure if that is something that Koha keeps track of or has readily available. But afaik it is true that we have a one-to-many mapping between plugins and plugin controllers, so a controller always "belongs" to one particular plugin – so a $c->plugin or $c->app->plugin should be unambiguous.