Hi all,
I am a bit worried that we will end up building a system for power
users, that have the option to extend Koha with local development to
make it fit. Let's also keep the users in mind, that don't have that
option and need a system that is flexible by configuration.
There is also the question what will make it into Core and how to handle
changes that might effect dependent modules. How much of the local
adaptations will be submitted to Koha proper and who will maintain them?
We have quite a lot of ongoing projects at the moment, but finding the
resources to keep them moving has been proven hard.
Katrin
On 10.04.2018 18:28, Julian Maurice wrote:
Hi Benjamin,
I have some concerns about this approach. You are saying that local
adaptations are reusable for others, but I don't see how. Deichman::*
will inevitably end up being highly specific. I could probably
copy/paste some code, but I think we will all have to write our own
MyLibrary::* stuff.
I'd prefer to extend the capabilities of plugins. This way we could
combine small generic plugins to answer specific needs.
But you also say that you reimplemented all the circulation stuff, and
that it was not complicated, so I'm curious :) Show us the code!
Le 10/04/2018 à 17:04, Benjamin Rokseth a écrit :
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/
