Haha, thanks :) Yes, Perl was the choice as it was already configured to connect to the Oracle database. I can't say I was very fluent in it back then (well, I still feel the same), but it did the job! --Ere dcook@prosentient.com.au kirjoitti 10.11.2020 klo 1.28:
Thanks, Ere!
That's amazing that WebVoyáge Enhancer worked for so long. Interesting use of Perl!
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-bounces@lists.koha-community.org> On Behalf Of Ere Maijala Sent: Tuesday, 10 November 2020 5:27 AM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Ideas for Koha Plugins
Hi,
Just a quick note to say that it sounds like a good idea to me. While keeping such plugin up to date might need some work (depending on which template it's touching and how often it changes), that would make many things possible without having to do much plumbing in the core code.
If anyone says this is never going to work or be worth the effort, I've actually done something similar long ago without any support from the system in question, and it worked surprisingly well (see https://developers.exlibrisgroup.com/blog/tomcatwebvoyageenhancer/ if you really want to know more :) ). We ran it for many years in production with little issues, though I must admit that there were not many updates to Voyager's OPAC to worry about.
--Ere
dcook@prosentient.com.au kirjoitti 5.11.2020 klo 2.07:
Hi all,
I was looking at Mark’s bug report at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890, and it got me thinking about how we use Koha Plugins (amongst other things).
I think it would be interesting to let Koha plugins touch the $template object before $template->output is called. That would give Koha plugins a lot more power without having to hardcode in specific methods and such into Perl scripts. The Perl script could lookup Koha plugins using a hard-coded key (e.g. opac/opac-detail.pl or opac/opac-detail), and then it would be the job of the Koha plugin to take things from there.
As a related aside, at some point, I’m planning to replace “output_html_with_http_headers” and “output_with_http_headers” (as part of Bug 26845 probably), but I’m not quite there yet. I’m slowly in the process of building Mojolicious controllers to replace our CGI scripts, and I’m hoping to refactor some vital components of Koha so that our CGI scripts keep working, but the new Mojolicious controllers are able to re-use the same code and stay consistent.
Anyway, it’s just an idea. We could implement it in “output_html_with_http_headers”, or we could just implement it in some important scripts like opac-detail.pl. I don’t have any particular use-cases in mind (besides Mark’s).
Another idea would be to put more of the UI logic into Javascript and hook plugins in more dynamically with the Javascript at a per-page level (rather than only via IntranetUserJS and OpacUserJS), but I haven’t thought too much about that.
David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Online: 02 8005 0595
_______________________________________________ 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/
-- Ere Maijala Kansalliskirjasto / The National Library of Finland