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

Not found : blackdot.gif...
by Jerome Vizcaino 14 May '03

14 May '03

Hello I'm experiencing this annoying message in the koha-error.log file every time I access a page in Koha [error] [client x.x.x.x] File does not exist : /home/koha/intranet/htdocs/images/blackdot.gif Can anyone tell me what this file is used for. It doesn't seem to exist in my 1.9.2 version :( It is not really a major problem but pollutes the log file with many occurences... Thanks Jerome

5 8

[PERL4LIB] Interlibrary loan (fwd)
by Pat Eyler 14 May '03

14 May '03

This is a very nice development from the world outside Koha. Anyone want to look into what it would take to get this into 2.0.1 or 2.0.2 (we're too late for 2.0.0 given the nearness of Paul's feature freeze.) -pate ---------- Forwarded message ---------- Date: Wed, 14 May 2003 09:07:39 -0500 From: david <DChristensen(a)westman.wave.ca> To: PERL4LIB(a)listserv.rice.edu Subject: [PERL4LIB] Interlibrary loan Hi everyone, Well, I've got a simple package built that allows you to create a proper GS message (Simon Fraser Univeristy was able to import it - thanks, Scott!). Before I put it up on CPAN, though.... any thoughts on what namespace it should live in? I was thinking ILL::GS, or maybe LIBRARIES::ILL::GS (but there is the confusion of book-libraries vs. code-libraries). -David Christensen

1 0

Re: [Koha-devel] Koha Intranet Interface - Navigation Question
by Rachel Hamilton-Williams 14 May '03

14 May '03

Hi Paul http://katipo.co.nz/gallery/koha/Aquisitions_1 How does this look to you? Cheers Rachel_____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org

2 1

Re: [Koha-devel] Koha, coding style and templates
by Owen Leonard 13 May '03

13 May '03

> One more idea : > in templates, how to write HTML ? ... > 3- as required in w3c html : everything in right > part of a token has "" I'd be all for making templates XTHML-Transitional. Barring full compliance with that standard, I would suggest at the very least these guidlines: - All HTML tags in lower case (HTML:Template tags in uppercase is fine of course) - All attribute values are quoted (<table border="0"> instead of <table border=0> - No 'minimization' of attributes, so <input type="checkbox" checked> is changed to <input type="checkbox" checked="checked"> XHTML requires that all tags be closed, so tags like <br> become <br /> This may be too much hassle for those who don't care about XHTML-compliance, so at minimum that 'optional' end tags be used: <p></p> <li></li> <option></option> These kind of changes are only a minor alteration in normal HTML markup writing, and will make it easier for those who want to go as far as adding the XHTML DocType and moving to full XHTML compliance. What do others think? -- Owen ---- Nelsonville Public Library Koha 1.9.2

1 0

FW: [Koha-devel] Koha, Style, and Perltidy
by Anthony W Youngman 13 May '03

13 May '03

Whoops - sent to MH only - the other list i'm a lot more frequent contributor to always sends stuff to the list regardless of which reply you hit ... Cheers, Wol -----Original Message----- From: Anthony W Youngman Sent: 13 May 2003 11:07 To: 'Mike Hansen' Subject: RE: [Koha-devel] Koha, Style, and Perltidy Paul has said what he - as a major contributor - prefers. What I would suggest is that you enforce all code committed to CVS to be run through whatever the standard "perltidy" is as it's checked in. That way you enforce consistency within the codebase. I don't know if you can make the checkout run through a similar perltidy to convert it to the relevant programmer's preferences? Certainly make sure the FAQ tells them how to make it format to their preferences. Certainly, if you demand that code WILL be run through perltidy, therefore it is a requirement that it is "perltidy friendly", then I don't see that the choice of codebase formatting is of any importance. If a programmer doesn't like the default, he simply has to use perltidy to his preferences on checkin and checkout. Cheers, Wol -----Original Message----- From: Mike Hansen [mailto:mwhansen@hmc.edu] Sent: 13 May 2003 06:58 To: Koha Devel Subject: [Koha-devel] Koha, Style, and Perltidy 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.

1 0

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