May 2003 - Koha-devel - lists.koha-community.org

Koha, Style, and Perltidy
by Mike Hansen 13 May '03

13 May '03

Hello everyone, It has been suggested a number of times before that we come up with a standard style for Koha scripts in order to make the scripts easier to read. One such way of doing this is using a program called perltidy to go through and format things in a certain style. Perltidy can read its configuration from a seperate file, which would allow us to maintain consistency within the codebase. Now, there are a number of options that we should decide on before we can effectively use perltidy. I will present some of the major options here along with their alternatives and some sample pieces of code formatted with the various options. 1. Line length: This setting will prevent lines of code from exceeding a maximum number of characters. The default length is 80 columns. Do we want it do be more or less or the same? 2. Indentation: There are a number of ways that perltidy handles indentation. First, you can specify a number of spaces to ident code blocks. Shown below is the indentation set to 4 spaces: if ( $flag eq "a" ) { $anchor = $header; } We can change this value to anything we would like. We can also set it to use tabs instead of spaces to indent. 3. Opening Brace Right or Left: This setting controls where the opening brace for code blocks go. Below is an exmaple with them on the right: if ( $flag eq "h" ) { $headers = 0; } and on the left: if ( $flag eq "h" ) { $headers = 0; } Which one of these should we use? 4: Cuddled Else: The cuddled else style is shown below: if ( $flag eq "h" ) { $headers = 0; } elsif ( $flag eq "f" ) { $sectiontype = 3; } else { print "invalid option: " . substr( $arg, $i, 1 ) . "\n"; dohelp(); } while the non-cuddled else is: if ( $flag eq "h" ) { $headers = 0; } elsif ( $flag eq "f" ) { $sectiontype = 3; } else { print "invalid option: " . substr( $arg, $i, 1 ) . "\n"; dohelp(); } Which one is preferable. 5. Horizontal Tightness: This controls the spacing for items in "containers." Here are the various options: if ( ( my $len_tab = length( $tabstr ) ) > 0 ) { # -pt=0 if ( ( my $len_tab = length($tabstr) ) > 0 ) { # -pt=1 (default) if ((my $len_tab = length($tabstr)) > 0) { # -pt=2 Note that that was for parentheses. There are similar options for square brackets, curcly braces, and code block curly braces. Those are a few of the major ones; however, there are more options at http://perltidy.sourceforge.net/stylekey.html. If you can think of anything else that would be beneficial style-wise, let me know. If you would please give me your comments and opinions (preferably along with why you think that way would be best for Koha), I would greatly appreciate it. Hopefully we will be able to get a standard style for Koha from this thread. Thanks, Mike -- Mike Hansen <mwhansen(a)hmc.edu>

3 3

Template default name
by Jerome Vizcaino 13 May '03

13 May '03

Hello We've been looking around Koha 1.9.2 to add our own template. In the system preferences tab there is a template field. Surprisingly, changing its value doesn't change anything. We had copied the whole 'default' directory to a 'test' directory then changed the 'default' value to 'test' in Koha. The template name seems to be returned by the Koha C4 perl module so we took a look at it. It ends to a $theme variable which seems to get the name of the template from the database (Output.pm file line 91). $theme is generated by a 'pathtotemplate' function (located in Output.pm line 206) but this function seems to be bugged. To get $theme it calls Context::preference with a "theme" parameter (line 221). Preference executes the following SQL statement : "SELECT value FROM systempreferences WHERE variable='themes' LIMIT 1;" Our "systempreferences" table doesn't have a themes variable but a template one. Changing the parameter from "theme" to "template" doesn't change anything. Is there another place where the template parameter is re-defined or is it a bug ? Thank you Jerome

2 2

[Fwd: Re: [Koha-devel] branchcategories => what's done for ?]
by Finlay Thompson 12 May '03

12 May '03

Hi Paul, I thought I should add something about the branchcategories table. This was set up because HLT wanted Koha to distinguish between different types of branch: 1) the branch as a physical building. HLT have four branches in different towns. 2) branch as a physical location. This can be "Mending" or "Processing" which mean that the item is in the back room of the library. The "holdingbranch" field on the items table holds a branchcode that points at an actual physical branch, either an actual branch or in mending etc. This field changes often. 3) the branch as a collection of books. HLT divides up their collection into items that belong in at a particular library (physical branch) and should always go back to that branch, or "Circulating". Those are items that can move between different branches. The "homebranch" field on the items table holds a branchcode that points at the collection branch that the item belongs to. This field seldom changes. The idea with the branchcategories and branchrelations table was to provide a way of distinguishing programmatically between the various types of branches. The logic of circulations depends on the different types of branches. Im not sure that they way it is currently implemented is correct though. In hindsite, I think it would be better to have two tables, "branches" and "collections", (and even "libraries"). The current setup overloads the branches table a little too much, and the branchcategories and branchrelations tables represent an effort to get around that. If you drop those tables from the database it could break the code in the Circulations. I havnt had a look recently, so Im not sure how much it still depends on it. Moveover, HLT need to have some way of managing the different types of branches, so if you do drop it you might want to bear that in mind. Hope that is helpful, Finlay paul POULAIN wrote: > Chris Cormack wrote: > >> I hope this makes it somewhat clearer, and that I have explained it. >> >> Rosalie may have some comments too. >> > Yes, it's clear. > But the consequence is still not 100% clear : As the code does not > manage those constraints, it's just a "reminder". > So it could be dropped without harm am I right ? > If we want to keep it, constraints should be added, but that's not in > the scope of the 2.0.0 imho. >

1 0

[Fwd: Re: [Koha-devel] branchcategories => what's done for ?]
by Finlay Thompson 12 May '03

12 May '03

Hi Paul, I thought I should add something about the branchcategories table. This was set up because HLT wanted Koha to distinguish between different types of branch: 1) the branch as a physical building. HLT have four branches in different towns. 2) branch as a physical location. This can be "Mending" or "Processing" which mean that the item is in the back room of the library. The "holdingbranch" field on the items table holds a branchcode that points at an actual physical branch, either an actual branch or in mending etc. This field changes often. 3) the branch as a collection of books. HLT divides up their collection into items that belong in at a particular library (physical branch) and should always go back to that branch, or "Circulating". Those are items that can move between different branches. The "homebranch" field on the items table holds a branchcode that points at the collection branch that the item belongs to. This field seldom changes. The idea with the branchcategories and branchrelations table was to provide a way of distinguishing programmatically between the various types of branches. The logic of circulations depends on the different types of branches. Im not sure that they way it is currently implemented is correct though. In hindsite, I think it would be better to have two tables, "branches" and "collections", (and even "libraries"). The current setup overloads the branches table a little too much, and the branchcategories and branchrelations tables represent an effort to get around that. If you drop those tables from the database it could break the code in the Circulations. I havnt had a look recently, so Im not sure how much it still depends on it. Moveover, HLT need to have some way of managing the different types of branches, so if you do drop it you might want to bear that in mind. Hope that is helpful, Finlay paul POULAIN wrote: > Chris Cormack wrote: > >> I hope this makes it somewhat clearer, and that I have explained it. >> >> Rosalie may have some comments too. >> > Yes, it's clear. > But the consequence is still not 100% clear : As the code does not > manage those constraints, it's just a "reminder". > So it could be dropped without harm am I right ? > If we want to keep it, constraints should be added, but that's not in > the scope of the 2.0.0 imho. >

1 0

Bibliothesaurus table
by Jerome Vizcaino 12 May '03

12 May '03

Hello Inspecting the acquisition process we found that the editors popup didn't worked. The problem comes from the unimarc_210c.pl and thesaurus_popup.pl. The SQL instructions are looking for a 'father' field in the bibliothesaurus table. Unfortunately, this field doesn't exist. Can someone tell me what was this field used for and what is its new name ? (the hierarchy field maybe ?) Thank you Jerome

3 3

Re: [Koha-devel] Bibliothesaurus table
by Jerome Vizcaino 12 May '03

12 May '03

Hello Paul Nope we didn't upgrade an old Koha version. We installed Koha 1.9.2 on a clean Debian Woody install. However we didn't install the sample information in the database. Maybe this is the problem. By the way the installation of Koha was a real problem and we had to install all the required Perl modules by hand due to a problem with the CPAN module. Building a debian package for Koha would be a good idea. If anyone knows how to do this... Jerome paul POULAIN wrote: > Jerome Vizcaino wrote: > >> Hello >> >> Inspecting the acquisition process we found that the editors popup >> didn't worked. >> The problem comes from the unimarc_210c.pl and thesaurus_popup.pl. >> The SQL instructions >> are looking for a 'father' field in the bibliothesaurus table. >> Unfortunately, this field doesn't exist. >> Can someone tell me what was this field used for and what is its new >> name ? (the hierarchy field maybe ?) > > > The bibliothesaurus table should be : > CREATE TABLE bibliothesaurus ( > id bigint(20) NOT NULL auto_increment, > freelib char(80) NOT NULL default '', > stdlib char(80) NOT NULL default '', > category char(10) NOT NULL default '', > father char(80) default NULL, > level tinyint(4) NOT NULL default '1', > hierarchy char(80) NOT NULL default '', > PRIMARY KEY (id), > KEY freelib (freelib), > KEY hierarchy (hierarchy), > KEY father (father), > KEY stdlib (stdlib), > KEY category (category), > FULLTEXT KEY category_2 (category,freelib) > ) TYPE=MyISAM; > > Why is the father row missing in your install is a good question ? Did > you upgrade from a 1.9.1 DB (we spoke of such an upgrade with Serge > IIRC)? > In updater/updatedatabase, line 109, the father table is here. > So... >

4 3

new developers
by Pat Eyler 12 May '03

12 May '03

In the course of the last week, I've added two new developers (from France) to our Sourceforge site. It looks like I'll be getting to add a couple more (from Argentina) in the near future. I'm really excited to see more groups joining up with Koha, and I can't wait to see the kinds of things that start happening. Let me take this opportunity to talk about four things: 1) If you're interested in working on Koha, please let Chris, Paul, or I know. We can always use people who want to work on coding, testing, writing documentation, or what have you. Even if your Perl skills aren't the greatest, there are plenty of ways you can contribute. 2) If you are registered as a developer, but you haven't been active in the last year or so, please get in touch with me. I promise I won't try to talk you into working on the project, I just want to see if you're still there and still interested. 3) We're hitting the home stretch towards 2.0.0, this means we need to be extra careful about what we do with our sourcecode. If you're a developer and you've got an idea for a cool new feature, please DON'T add it to koha yet. If you've just got to work on it, please do so outside the normal cvs tree -- once 2.0.0 is out, we'll be relaxing this stance. 4) If you want to work on Koha, but don't know where to start, please take a look at bugs.koha.org ... there are a lot of little things that need to be fixed. Please feel free to grab a bug and squash it. thanks, -pate

3 3

Bugzilla summary for last 3 days
by chris＠wilbur.katipo.co.nz 12 May '03

12 May '03

16 bugs found. ID Sev Pri Plt Owner State Result Summary 216 enh P2 PC tonnesen(a)cmsd.bc.ca NEW installer should create an initial librarian user account http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=216 239 nor P4 PC chris(a)katipo.co.nz NEW Issue limit doesn't work - able to check out more items than http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=239 242 nor P2 PC paul.poulain(a)free.fr NEW Current loan output is blank http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=242 377 maj P2 PC tonnesen(a)cmsd.bc.ca NEW Branch Category page does not allow adding or editing catego http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=377 387 nor P2 PC paul.poulain(a)free.fr REOP Request output does not show pick-up location in select list http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=387 417 blo P2 PC tonnesen(a)cmsd.bc.ca REOP installer.pl wants root http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=417 436 nor P2 PC chris(a)katipo.co.nz NEW circulation.pl only partially templated http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=436 437 enh P2 PC chris(a)katipo.co.nz NEW 'Browse Members' function should return paged results http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=437 439 nor P2 All paul.poulain(a)free.fr NEW Member search from circulation.pl will only search by last n http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=439 440 nor P2 PC chris(a)katipo.co.nz NEW JavaScript function openWindow is not defined http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=440 441 nor P2 PC paul.poulain(a)free.fr NEW Z39.50 search link doesn't work http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=441 443 nor P2 PC paul.poulain(a)free.fr NEW Adding a child creates that child in triplicate http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=443 444 maj P2 PC paul.poulain(a)free.fr NEW No where to add types for Manual Credit or Manual Invoice http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=444 450 min P2 PC paul.poulain(a)free.fr NEW Can't add supplier where List Item Price Includes GST http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=450 452 nor P2 PC paul.poulain(a)free.fr NEW Payment due flags not showing up for children http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=452 456 blo P2 PC paul.poulain(a)free.fr NEW Hardwired config file location http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=456 16 bugs found. Long Format Query Page Enter New Bug Change columns Edit this query

3 2

branchcategories => what's done for ?
by paul POULAIN 12 May '03

12 May '03

I spend a few minuts on bug #377 and related. I want to know what the branchcategories table is done for. It seems to be unused : * branchcategories has a row "categorycode". * branchrelation has a branchcode and a categorycode row. It means it's a relation between branches and branchcategories. but... Those infos seems to be used nowhere (a grep "branchrelations" and grep "branchcategories" reports values in installer and admin script only) . So, unless someone (katipo ?) explain what it's supposed to do (and where :-) ), it will be dropped soon... -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

3 4

Another acquisition module ?
by Jerome Vizcaino 12 May '03

12 May '03

Hello I'm working with another student at ESIEE (Michel Lerenard) on an implementation of the Koha 1.9.x system for our school library. Serge Renaux is leading us in this task. It will lead to an install of the Koha 2 system when ready. As our library uses a slightly different way to acquire documents, we have to rearrange the way information are entered by the user. We figured out that one way to do it is to create another template directory and to configure Koha to use this directory. It seems that in our case, template modification is not sufficient so we were thinking of a solution based on another acquisition module. There is already an option in Koha that sets the type of acquisition (normal or simple) but this option doesn't seem to work (we are using Koha 1.9.2). Therefore, our first question is "Is this option not working due to a bug or because of a "non implemented yet" function ?" Our second question is : "Will it be possible to set the option to "esiee" for example so that Koha will use the Perl scripts localised in a "acqui.esiee" directory ?" Thank you in advance. Sincerely Jerome Vizcaino

3 4