[Koha-devel] Ideas for Koha Plugins

[Ere Maijala]

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 at 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 at 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