Mmmm tempting but dangerous indeed.
I'd say plugins in a software must be additions of features, modifying
features is forking.
Best regards,
Le 11/11/2020 à 23:41, dc...@prosentient.com.au a écrit :
I wouldn't say impossible to maintain, but that's a good point about competing
plugins trying to override the same modules.
Your critique of my @INC idea would also apply to giving plugins access to the
Mojolicious router though. Overriding via plugins is probably not a sensible
solution.
I am somewhat familiar with Mojolicious plugins, and that's an interesting
idea, although those should really be set at app startup time. (I have been
wondering how we could improve the Koha plugin experience by getting all
Starman workers to reload to include new plugin code...)
I think both the Mojolicious plugins and modifying @INC could be useful for
sysadmins but probably not Koha end users - now that I think about it more.
Speaking of Mojolicious, feel free to add your CC to Bug 26791, Julian. I
haven't posted my patches yet, but I'm sure your feedback will be useful when I
do. I'm planning to replace the export.pl script with a Mojolicious controller.
I just need to find some time to finish it off.
David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Online: 02 8005 0595
-----Original Message-----
From: Koha-devel <koha-devel-boun...@lists.koha-community.org> On Behalf Of
Julian Maurice
Sent: Wednesday, 11 November 2020 9:46 PM
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Location of plugins in @INC
Le 11/11/2020 à 01:17, dc...@prosentient.com.au a écrit :
Hi all,
I was talking about how we could override default Koha modules with
customized versions by just making sure those modules were located
earlier in @INC.
That got me thinking… at the moment we put Koha Plugins at the bottom
of @INC, but we could actually put them at the start of @INC.
They would be more dangerous as they’d be able to override any Perl
module… but they would also be more powerful.
More powerful, and quite impossible to maintain, as every change to the module
would have to be done in the plugin as well :/ Also, two plugins overriding the
same module... It just won't work.
In the context of a Koha where controllers are Perl modules (e.g.
Mojolicious controllers) rather than Perl scripts, a plugin could
override any controller in Koha. That could make for very powerful and
seamless customizations.
For this particular use case I think there are better options, like giving
plugins access to the Mojolicious router, which allows to override some routes.
Also note that Mojolicious has its own plugin system that can be used as well.
For now the list of plugins used by Mojolicious applications is static, but it
certainly can be made dynamic without much effort.
--
Fridolin SOMERS <fridolin.som...@biblibre.com>
Software and system maintainer 🦄
BibLibre, France
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
