Re: [Koha-devel] Koha Core anyone?

[David Cook]

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 

Re: [Koha-devel] Koha Core anyone? (Benjamin Rokseth)

[Benjamin Rokseth]

Hi, and thanks for quick feedback folks.

Good catch, Jonathan, we recently moved to gitlab since they integrate devops 
and CI build tools. The branch circ_rewrite_master is rebased against master, 
but havent tested properly yet, so its very WIP but you'll get the general idea.


Julian,​

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

Your concern is probably sound, since it is easier to add all local adaptations 
to a local namespace (Deichman::*) and be done with it. What I'd suggest though 
is that modules are kept as atomic as possible so that anything can possibly be 
overridden. Its kind of the opposite of todays practise where sysprefs are 
scattered all over the code to adjust for local variations, at least from what 
I've seen in the C4::Circulation. I think it would make sense to allow for a 
Core Circulation that never touch sysprefs, while at the same time having a 
"default" or "full-blown" implementation that can do exactly what 
C4::Circulation does today.

> I'd prefer to extend the capabilities of plugins. This way we could
> combine small generic plugins to answer specific needs.

Actually, I didnt realize plugins was more than tools to extend reports, kind 
of a stepwise db tooling. At least the examples I saw was just CGI templates 
that must be aactively run to modify database. And they seemed based on CGI 
templating which doesnt help us much. In any case, to plug into something 
central, such as Circulation, the circulation modules would need to be 
rewritten.

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


WIP for sure, but as Jonathan found out, here is a single commit on top of 
master

https://gitlab.deichman.no/digibib/Koha/commits/circ_rewrite_master

I see now we use a local caching trick with method attributes (PureFunctions) 
that is not included, so I will have to remove that or it will not work at 
present. But if theres some interest, I will open a bug and commit so people 
can test it. I will try to commit at least to make circulation work as in a 
standard installation.


Benjamin


Fra: Brendan Gallagher 
Sendt: 10. april 2018 21:34
Til: Jonathan Druart
Kopi: Benjamin Rokseth; koha-devel@lists.koha-community.org
Emne: Re: [Koha-devel] Koha Core anyone?

Very excited by this idea.  Lot's to think about.  We're on board with most of 
it and are ready to help.

Cheers,
Brendan

On Tue, Apr 10, 2018 at 9:30 AM, Jonathan Druart 
>
 wrote:
Ha, found it!
https://gitlab.deichman.no/digibib/Koha/commits/circ_rewrite_master
I was looking at the digibib github repo!


On Tue, 10 Apr 2018 at 13:28 Jonathan Druart 
>
 wrote:
Hi Benjamin,

Where is the code of the "working example"?

Cheers,
Jonathan

On Tue, 10 Apr 2018 at 12:04 Benjamin Rokseth 
> wrote:
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 |
| ...   | |  |   +---^---+
+---+ |  |   |
  |  |   |
   +--+--+   +--+
   

[Koha-devel] Documentation meeting reminder

[Lee Jamison]

Just a reminder there will be a documentation meeting tomorrow at 21 UTC

https://wiki.koha-community.org/wiki/Documentation_IRC_meeting_11_April_2018

-- 
Lee Jamison
Automated Library Technician
Marywood University
570-961-4586
ldjami...@marywood.edu
___
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] Reminder: Development IRC meeting 11 April 2018

[Katrin Fischer]

Hi all,

tomorrow is our next Developer IRC meeting:

https://wiki.koha-community.org/wiki/Development_IRC_meeting_11_April_2018

Planned topics so far include:

- voting on several REST API endpoints
- discussion on Authentication for the REST API
- discussion on improving update procedures

Please add anything else you wish to discuss.

See you all tomorrow!

Katrin


___
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/

Re: [Koha-devel] Koha Core anyone?

[Katrin Fischer]

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 

Re: [Koha-devel] Koha Core anyone?

[Brendan Gallagher]

Very excited by this idea.  Lot's to think about.  We're on board with most
of it and are ready to help.

Cheers,
Brendan

On Tue, Apr 10, 2018 at 9:30 AM, Jonathan Druart <
jonathan.dru...@bugs.koha-community.org> wrote:

> Ha, found it!
> https://gitlab.deichman.no/digibib/Koha/commits/circ_rewrite_master
> I was looking at the digibib github repo!
>
>
> On Tue, 10 Apr 2018 at 13:28 Jonathan Druart  community.org> wrote:
>
>> Hi Benjamin,
>>
>> Where is the code of the "working example"?
>>
>> Cheers,
>> Jonathan
>>
>> On Tue, 10 Apr 2018 at 12:04 Benjamin Rokseth <
>> benjamin.roks...@deichman.no> wrote:
>>
>>> 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 

Re: [Koha-devel] Koha Core anyone?

[Jonathan Druart]

Ha, found it!
https://gitlab.deichman.no/digibib/Koha/commits/circ_rewrite_master
I was looking at the digibib github repo!

On Tue, 10 Apr 2018 at 13:28 Jonathan Druart <
jonathan.dru...@bugs.koha-community.org> wrote:

> Hi Benjamin,
>
> Where is the code of the "working example"?
>
> Cheers,
> Jonathan
>
> On Tue, 10 Apr 2018 at 12:04 Benjamin Rokseth <
> benjamin.roks...@deichman.no> wrote:
>
>> 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 : 

Re: [Koha-devel] Koha Core anyone?

[Julian Maurice]

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 

Re: [Koha-devel] Koha Core anyone?

[Jonathan Druart]

Hi Benjamin,

Where is the code of the "working example"?

Cheers,
Jonathan

On Tue, 10 Apr 2018 at 12:04 Benjamin Rokseth 
wrote:

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

[Koha-devel] Koha Core anyone?

[Benjamin Rokseth]

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/

Re: [Koha-devel] Printing patron cards results in 100% cpu

[Fridolin SOMERS]

Hi,

I have seen something on the doc of this lib :
https://metacpan.org/pod/PDF::FromHTML#-tags

Add the height and width attributes if you are creating the source HTML, 
it keeps PDF::FromHTML from having to open and read the source image 
file to get the real size. Less file I/O means faster processing.


Maybe it is this problem.

Regards,

Le 01/04/2018 à 21:43, Sven Halm a écrit :

Hello and happy Easter!

I have a problem with the patronage card printing. I also described the problem 
in Bug 20077. I got a tip from Katrin to try the mailing list.

When I try to print the patron cards, the 
/usr/share/koha/intranet/cgi-bin/patroncards/create-pdf.pl does not finish and 
runs with 100% CPU load.

In plack-error.log I find the following lines:
Use of uninitialized value $batch_id in concatenation (.) or string at 
/usr/share/koha/intranet/cgi-bin/patroncards/create-pdf.pl line 68.
Use of uninitialized value in multiplication (*) at 
/usr/share/koha/lib/C4/Patroncards/Patroncard.pm line 239.
Use of uninitialized value in addition (+) at 
/usr/share/koha/lib/C4/Patroncards/Patroncard.pm line 256.
Use of uninitialized value in multiplication (*) at 
/usr/share/koha/lib/C4/Patroncards/Patroncard.pm line 288.
Use of uninitialized value in multiplication (*) at 
/usr/share/koha/lib/C4/Patroncards/Patroncard.pm line 239.
Use of uninitialized value in addition (+) at 
/usr/share/koha/lib/C4/Patroncards/Patroncard.pm line 256.
Use of uninitialized value in multiplication (*) at 
/usr/share/koha/lib/C4/Patroncards/Patroncard.pm line 288.
Use of uninitialized value in multiplication (*) at 
/usr/share/koha/lib/C4/Patroncards/Patroncard.pm line 239.
Use of uninitialized value in addition (+) at 
/usr/share/koha/lib/C4/Patroncards/Patroncard.pm line 256.

The problem first appeared in February 2018 after I started the Ubuntu updates. 
Unfortunately I don't remember what has been updated.

Current system environment (no changes made to koha!):
OS: Ubuntu 17.10
Koha-Version:
17.11.04.000
OS Version ('uname -a'):
Linux koha 4.13.0-37-generic #42-Ubuntu SMP Wed Mar 7 14:13:23 UTC 2018 x86_64
Perl Interpreter:
/usr/bin/perl
Perl-Version:
5.026000
Perl @INC:
/usr/share/koha/lib
/usr/share/koha/installer
/usr/share/koha/lib/installer
/etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.26.0
/usr/local/share/perl/5.26.0
/usr/lib/x86_64-linux-gnu/perl5/5.26
/usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.26
/usr/share/perl/5.26
/usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base
MySQL-Version:
mysql Ver 15.1 Distrib 10.1.30-MariaDB, for debian-linux-gnu (x86_64) using 
readline 5.2
Apache-Version:
Server version: Apache/2.4.27 (Ubuntu)


Unfortunately I am not able to print patron cards at the moment. It would be 
great if there was a solution for this soon.

Many greetings
Sven




___
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/



--
Fridolin SOMERS 
BibLibre, France - software and system maintainer
___
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/

Re: [Koha-devel] Default Elasticsearch behaviour wrong with Chinese: can't find complete title

[Nicolas Legrand]

Removing  QueryAutoTruncate was the trick, everything looks pertinent now!

2018-04-05 11:09 GMT+02:00 Nicolas Legrand :

> For what it's worth, we also use Latin script language and find the
> results more relevant without a star, or at least with the queries of 17.05
> :).
>
> 2018-04-04 13:10 GMT+02:00 Nick Clemens :
>
>> Interesting, yes, the star was added to support auto_truncation and
>> enabled by default. For languages using latin scripts we need the star,
>> otherwise a search for "cat" will not return results containing "cats"
>>
>> I am not sure what the path to correcting this is - I think you should
>> file a bug report with this info and we can take a deeper look into how we
>> are building our searches and what we can do.
>>
>> On Tue, Apr 3, 2018 at 10:22 AM Nicolas Legrand 
>> wrote:
>>
>>> Good day devs,
>>>
>>> Nick spotted these one during last Marseille Hackfest. We made some test
>>> with our catalogue on master and find out how to reproduce it, how to break
>>> it and how to fix it, though the inner mechanics remains a mystery and we
>>> are not quite sure about what the default behaviour should be.
>>>
>>> We did our test with 中國翻譯 (Chinese Translators Journal) which have two
>>> words highly present in our Catalog: China and translation.
>>>
>>> First, the default Koha behaviour is to add a "*" at the end of the
>>> searched word, which lead to 0 results. It produces a query looking like
>>> this one:
>>>
>>> $ curl  "http://localhost:9200/koha_robin_biblios/_search?pretty; -d
>>> '{"from": 0, "size": 0,"query":{"query_string":{"query": "中國翻譯*"}}}'
>>> {
>>>   "took" : 1,
>>>   "timed_out" : false,
>>>   "_shards" : {
>>> "total" : 5,
>>> "successful" : 5,
>>> "skipped" : 0,
>>> "failed" : 0
>>>   },
>>>   "hits" : {
>>> "total" : 0,
>>> "max_score" : 0.0,
>>> "hits" : [ ]
>>>   }
>>> }
>>>
>>> If we quote 中國翻譯 in Koha, it yields one answer, the right one. It
>>> produces a query looking like this one:
>>>
>>> $ curl  "http://bouse02.prive.bulac.fr:9200/koha_robin_biblios/_sear
>>> ch?pretty" -d '{"from": 0, "size": 0,"query":{"query_string":{"query":
>>> "\"中國翻譯\""}}}'
>>> {
>>>   "took" : 5,
>>>   "timed_out" : false,
>>>   "_shards" : {
>>> "total" : 5,
>>> "successful" : 5,
>>> "skipped" : 0,
>>> "failed" : 0
>>>   },
>>>   "hits" : {
>>> "total" : 1,
>>> "max_score" : 0.0,
>>> "hits" : [ ]
>>>   }
>>> }
>>>
>>> Note that if I write an Elasticsearch query without quotes or star, it
>>> yields too much results (9626), the “right” result isn't in the ten first
>>> results:
>>>
>>> $ curl  "http://bouse02.prive.bulac.fr:9200/koha_robin_biblios/_sear
>>> ch?pretty" -d '{"from": 0, "size": 0,"query":{"query_string":{"query":
>>> "中國翻譯"}}}'
>>> {
>>>   "took" : 16,
>>>   "timed_out" : false,
>>>   "_shards" : {
>>> "total" : 5,
>>> "successful" : 5,
>>> "skipped" : 0,
>>> "failed" : 0
>>>   },
>>>   "hits" : {
>>> "total" : 9626,
>>> "max_score" : 0.0,
>>> "hits" : [ ]
>>>   }
>>> }
>>>
>>>
>>> I'm not sure what the right behaviour needs to be. We felt adding quotes
>>> added a lot of relevance to our results no matter what the language is.
>>> What is certain is that adding a star to the search by default doesn't help
>>> us. We didn't have the problem with Elasticsearch while playing with it in
>>> 17.05. For us, it is a regression. I add the MARC of our test record.
>>>
>>> What do you think about it?
>>>
>>> Best regards,
>>>
>>> --
>>>
>>> *Nicolas Legrand*
>>> Administration technique et développements du système de gestion de la
>>> bibliothèque
>>>
>>> [image: Logo BULAC]
>>>
>>> Bibliothèque universitaire
>>> des langues et civilisations
>>>
>>> 65 rue des Grands Moulins
>>> 
>>> F-75013 PARIS
>>> T +33 1 81 69 *18 22*
>>> www.bulac.fr
>>> ___
>>> 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/
>>
>> --
>> Nick Clemens
>> Sonic Screwdriver (Development Support)
>> ByWater Solutions
>> IRC: kidclamp
>>
>
>
>
> --
>
> *Nicolas Legrand*
> Administration technique et développements du système de gestion de la
> bibliothèque
>
> [image: Logo BULAC]
>
> Bibliothèque universitaire
> des langues et civilisations
>
> 65 rue des Grands Moulins
> F-75013 PARIS
> T +33 1 81 69 *18 22*
> www.bulac.fr
>



-- 

*Nicolas Legrand*
Administration technique et développements du système de gestion de la
bibliothèque

[image: Logo BULAC]

Bibliothèque universitaire
des langues et civilisations

65 rue des Grands Moulins
F-75013 PARIS
T +33 1 81 69 *18 22*
www.bulac.fr
___