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