<div dir="ltr">I wonder if a Decorator pattern would be useful. An even simpler situation would be to enable a before and after hook for each subroutine in Koha via plugins.<div><br></div><div>Kyle</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><a href="https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB" target="_blank"><img src="http://widgets.ch-or.us/badge/convio/cff/4715/2706639"></a><br></div><div><br></div><div><a href="http://www.kylehall.info" target="_blank">http://www.kylehall.info</a><br>ByWater Solutions ( <a href="http://bywatersolutions.com" target="_blank">http://bywatersolutions.com</a> )<br>Meadville Public Library ( <a href="http://www.meadvillelibrary.org" target="_blank">http://www.meadvillelibrary.org</a> )<br>Crawford County Federated Library System ( <a href="http://www.ccfls.org" target="_blank">http://www.ccfls.org</a> )<br></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Apr 10, 2018 at 7:22 PM, David Cook <span dir="ltr"><<a href="mailto:dcook@prosentient.com.au" target="_blank">dcook@prosentient.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It seems to me that the Deichman modules would become stale pretty quickly.<br>
<br>
Although, if there were a Koha Core which was fairly simple, maybe there<br>
wouldn't be many breaking changes introduced over time. <br>
<br>
I have thought a bit about something like this before, although I was more<br>
so interested in the OPAC. I thought it would be interesting to have a Koha<br>
Core OPAC that worked out of the box, but have the core functionality<br>
implemented with REST APIs so that people could embed Koha OPAC<br>
functionality in any website they wanted. <br>
<br>
I think Katrin has already said it but the great thing about Koha is that it<br>
is all things to all people. Thousands of libraries around the world rely on<br>
being able to customize it via configuration alone. One way or another, we'd<br>
have to preserve that even with a Koha Core model. So you might have<br>
Deichman::Circulation, but we'd still need a Community::Circulation which<br>
re-implements what we already have for the people who can't afford their own<br>
Organisation::Circulation. <br>
<br>
I suppose what I'm saying is... I'm sure the community will welcome patches,<br>
so long as you're able to preserve what's already there. And maybe that<br>
means refactoring C4::Circulation into Core::Circulation and<br>
Community::Circulation, and then Deichman can override Core::Circulation<br>
going forward while the community maintains Core:: and Community::. I can't<br>
imagine any objections to that.<br>
<br>
I haven't looked at the code that Jonathan linked, but I'm guessing that you<br>
have a separate user interface that invokes your Deichman::Circulation<br>
module anyway, so it wouldn't affect Koha per se. <br>
<br>
In any case, I think it's an interesting idea. I think Koha is currently a<br>
huge monolith and could benefit from further modularization that allows it<br>
to be easily extended. Of course, that could always fragment contributions<br>
to Koha... so vendors just provide their own flavours of Koha and don't<br>
contribute back to the Core, but that already happens to a degree out of<br>
necessity. Perhaps having a separate Core would make it easier to divide up<br>
the "patches that can be upstreamed" versus the "patches that are just<br>
relevant locally". <br>
<br>
Keen to hear more on this one.<br>
<br>
David Cook<br>
Systems Librarian<br>
Prosentient Systems<br>
72/330 Wattle St<br>
Ultimo, NSW 2007<br>
Australia<br>
<br>
Office: 02 9212 0899<br>
Direct: 02 8005 0595<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
-----Original Message-----<br>
From: <a href="mailto:koha-devel-bounces@lists.koha-community.org">koha-devel-bounces@lists.koha-<wbr>community.org</a><br>
[mailto:<a href="mailto:koha-devel-bounces@lists.koha-community.org">koha-devel-bounces@<wbr>lists.koha-community.org</a>] On Behalf Of Benjamin<br>
Rokseth<br>
Sent: Wednesday, 11 April 2018 1:04 AM<br>
To: <a href="mailto:koha-devel@lists.koha-community.org">koha-devel@lists.koha-<wbr>community.org</a><br>
Subject: [Koha-devel] Koha Core anyone?<br>
<br>
Community hackers,<br>
<br>
on hackfest I got introvertly enthusiastic about the concept of a Koha Core,<br>
and about time I shared some thoughts.<br>
<br>
Background: Deichman (Oslo Public Library) is heavily leaning on bleeding<br>
edge Koha development (REST, Objects, Auth, NCIP and such) and, like at<br>
least some others, maintain a lot of local patches to tweak Koha into our<br>
users needs. Some are probably interesting to Community, others not. Now to<br>
keep everything in sync with Community would be amazing, but not likely to<br>
happen anytime soon.<br>
<br>
Great work has been done on refactoring Koha (new namespace, Koha Objects<br>
and REST api, etc.), but we'd like to suggest one more - a Koha core.<br>
The idea is simple: borrow from object oriented languages, java, or actually<br>
more ruby, since we're dealing with a dynamic language, use class/module<br>
inheritance and method overrides.<br>
Perl has the "use parent" concept which simplifies inheritance/subclassing<br>
and allows for nested overrides.<br>
<br>
As an example we refactored the current circulation in Koha, since this for<br>
us is the core functionality that we depend on and need to hook our local<br>
quirks on top of.<br>
An attempt to illustrate:<br>
<br>
+------------+<br>
| Core::Main |<br>
+--^---------+<br>
|<br>
+--+----------------+<br>
| Core::Prefs |<br>
| Core::Exceptions | +-----------------------+<br>
| Core::Circulation <-----+------+---| Deichman::Circulation |<br>
| ... | | | +---^-------------------+<br>
+-------------------+ | | |<br>
| | |<br>
+------------------+------+ +--------------------------+<br>
| Core::Circulation::SIP | |Deichman::Circulation::SIP|<br>
+-----------------------------<wbr>------------------------------<wbr>-+<br>
| use parent qw(<br>
| Deichman::Circulation<br>
+----------------------+ Core::Circulation::SIP<br>
| Core::Circulation::UI| )<br>
+----------------------+<br>
|<br>
~<br>
<br>
* Core::Main is simply an empty class that act as a parent for any child,<br>
including Core::Circulation.<br>
* Core::Circulation has a constructor that takes koha objects item and<br>
library, optionally patron<br>
and sysprefs overrides. It can have accessors such as checkout, messages<br>
and other things needed for<br>
intra, SIP or whatever. It has methods Checkin, Checkout and Renew,<br>
amongst others.<br>
* then: Deichman::Circulation::SIP in this example is a local override that<br>
inherits from parents<br>
Deichman::Circulation and Core::Circulation::SIP<br>
<br>
now the beauty of this is that Deichman::Circulation::SIP can override<br>
anything (even the constructor) without touching any of the core code, and<br>
perl will traverse the inheritance tree until it finds the first matching<br>
constructor and method.<br>
<br>
Pros:<br>
- simpler, more readable and more reusable code.<br>
- local adaptations are easy to hande, and reusable for others<br>
- the slight overhead of using blessed objects and inheritance is easily<br>
gained by the fact that any<br>
operation will only need fetching Koha objects once (item,library,patron<br>
etc) instead of refetching<br>
them numerous times spread across methods calls and loops<br>
- way less db calls if done right, faster Koha<br>
- no more C4::Context, hopefully<br>
- systempreferences can be dramatically reduced, since most of them are<br>
about overrides anyways<br>
- can be done incrementally, replacing one functionality at a time<br>
<br>
cons:<br>
- refactoring doesnt make end users happy (but needs to be done in any<br>
case)<br>
- a bit of work to keep templates happy<br>
- requires a basic understanding of oop<br>
<br>
So to sum up: We already have a working example for circulation (though not<br>
in production) that we can demonstrate. It reimplements basically the entire<br>
C4::Circulation, just some small parts missing. So it can be done.<br>
<br>
But we'd love to hear second opinions from the community! We know the fear<br>
for breaking changes, but its neither scary or complicated to implement!<br>
<br>
Benjamin Rokseth<br>
Oslo Public Library<br>
______________________________<wbr>_________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-<wbr>community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" rel="noreferrer" target="_blank">http://lists.koha-community.<wbr>org/cgi-bin/mailman/listinfo/<wbr>koha-devel</a><br>
website : <a href="http://www.koha-community.org/" rel="noreferrer" target="_blank">http://www.koha-community.org/</a> git :<br>
<a href="http://git.koha-community.org/" rel="noreferrer" target="_blank">http://git.koha-community.org/</a> bugs : <a href="http://bugs.koha-community.org/" rel="noreferrer" target="_blank">http://bugs.koha-community.<wbr>org/</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-<wbr>community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" rel="noreferrer" target="_blank">http://lists.koha-community.<wbr>org/cgi-bin/mailman/listinfo/<wbr>koha-devel</a><br>
website : <a href="http://www.koha-community.org/" rel="noreferrer" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" rel="noreferrer" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" rel="noreferrer" target="_blank">http://bugs.koha-community.<wbr>org/</a><br>
</div></div></blockquote></div><br></div>