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 
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 
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 
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 
* 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.

  - 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

  - 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 
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
website :
git :
bugs :

Reply via email to