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

about "Replaced several prepare()/execute()/finish() sequences with do()."
by paul POULAIN 07 Oct '02

07 Oct '02

Just 1 remark about few of your CVS commits : we have decided to use prepare("update xx where yy=?"); execute($yy_value); If there are prepare("update xx where yy=$yy_value") execute(); then it's because nobody moved this query to ? syntax. Thus, - $query = "insert into biblio set - biblionumber = $bibnum, - title = $biblio->{'title'}, - author = $biblio->{'author'}, - copyrightdate = $biblio->{'copyright'}, - serial = $series, - seriestitle = $biblio->{'seriestitle'}, - notes = $biblio->{'notes'}, - abstract = $biblio->{'abstract'}"; ! $sth = $dbh->prepare($query); ! $sth->execute; should be $query = "insert into biblio set biblionumber = ? title = ? author = ? copyrightdate = ? serial = ? seriestitle = ? notes = ? abstract = ?"; $sth = $dbh->prepare($query); $sth->execute($bibnum,$biblio->{'title'},...); and not ! $dbh->do(<<EOT); ! INSERT INTO biblio ! SET biblionumber = $bibnum, ! title = $biblio->{'title'}, ! author = $biblio->{'author'}, ! copyrightdate = $biblio->{'copyright'}, ! serial = $series, ! seriestitle = $biblio->{'seriestitle'}, ! notes = $biblio->{'notes'}, ! abstract = $biblio->{'abstract'} ! EOT -- Paul

1 0

we've got a winner :-) => IMPORTANT
by paul POULAIN 07 Oct '02

07 Oct '02

I hope everybody has been VERY CAREFUL on C4::context.pm that Andrew posted yesterday... It's really a GREAT SCRIPT : * well documented * nice and clean perl * very useful. * extendable as we want and need. I think everybody should follow andrew paths... For the coming scripts, i STRONGLY recommend to use C4::context.pm and forget anything else... About parameters : ------------------------- I think we're on a dangerous way... some parameters are in /etc/koha.conf, some are in systempreferences table. I think, and chris too, that we should use koha.conf ONLY for DB parameters, and systempreferences for everything else. Example : it's bad, i think, to have theme in systempref and theme-path in koha.conf. Does anyone have an objection ? -- Paul

3 5

Search UI
by Andrew Arensburger 06 Oct '02

06 Oct '02

There's been some talk here about improving the searching code. It seems to me that a lot can be done by improving the user interface. Currently, the internal and OPAC search pages have three types of searches, but this isn't obvious. There's the search by bar code, which returns information about a specific item. There's the "fuzzy" search by author, title, etc. which searches for a combination of criteria. There's the subject search, which searches for known subjects, not books. On the internal search page, the barcode search is visually distinct from the other searches, so it's intuitively obvious that they're two different types of searches and should return different results. On the OPAC page, however, all of the fields are grouped together, giving the impression that it's just one tyep of search. If you see Author: _________________ Title: _________________ [Search] you naturally assume that you can fill in "Asimov" and "Astronomy", and get books with "Asimov" as the author AND "astronomy" in the title. Therefore, you conclude, if you see Author: _________________ Title: _________________ Subject: _________________ [Search] you can fill in "Asimov" as the author and "astronomy" as the subject, and get all the books written by Asimov on the subject of astronomy. This isn't what the page does: it ignores the author entirely, and displays a list of subjects that have the word "astronomy" in them. Likewise, it doesn't make sense to combine the barcode with anything else, such as an author. The barcode uniquely identifies a book, so either the author will match and return the same result as the barcode alone, or it won't and the search will return nothing. Finally, there's only one "OK Start Search" button on the page, which reinforces the impression that everything is part of one big search. This is true, actually: there's only one <form> block on the search page, and the code in C4/Search.pm jumps through all sorts of hoops to see which fields were specified and which ones weren't, and try to guess from that what kind of search the user wants to perform. IMHO it'd be better to start by changing the page layout: Keywords: ________________ Author: ________________ Title: ________________ (*) Normal ( ) Exact Series: ________________ (*) Normal ( ) Exact Illustrator: _____________ Subject: ________________ Item type: [Choose an item type] [Search] -------- Subject: ________________ [Search] -------- Barcode: ________________ [Search] (And maybe drop the Dewey search. I don't know.) For the first search, all of the terms would be combined: the search would return all books that match all of the criteria. The second search would return a list of subjects, the way it's currently done. The third search would find a specific book, as you'd expect. This layout seems more intuitive to me. (The in-store search thingy at Borders has a different interface: a pull-down selection box allows you to choose whether you want to search by author, title, or keyword. But I think the above is better, since it allows you to narrow the search by providing more terms.) The underlying HTML would then contain three <form> blocks. Each one could then include a field like <input type="hidden" name="type" value="by-barcode"> which would take the guesswork out of the code that actually performs the search and make it easier to Do The Right Thing. Thoughts? Opinions? Dissent? -- Andrew Arensburger This message *does* represent the arensb(a)ooblick.com views of ooblick.com A running program is the moment of truth. All else is either prophecy or nostalgia.

3 3

Circular dependencies
by Andrew Arensburger 06 Oct '02

06 Oct '02

I ran 'perl -wc' on a few of the C4 modules, and found that there are a number of circular dependencies, i.e., cases where two modules have "use" statements pointing at each other, or where Module1 uses Module2, which uses Module3, which uses Module1. Thanks to the magic of 'find | grep | tsort', I'm appending a list of these cycles at the end of this message. But 'perl -wc Module.pm' will also tell you if there's a cycle, by complaining that all of the functions in "Module.pm" are redefined. At first, I thought this meant that the first file in the loop would get read twice, but this doesn't appear to be the case. However, I think this does indicate spaghetti code and/or lack of modularity. -- Andrew Arensburger This message *does* represent the arensb(a)ooblick.com views of ooblick.com Do you want to make people's heads explode? Sure! We all do! C4/InterfaceCDK.pm C4/Circulation/Renewals.pm C4/Circulation/Issues.pm C4/Circulation/Main.pm C4/Reserves.pm C4/Interface/ReserveentCDK.pm C4/InterfaceCDK.pm C4/Accounts.pm C4/Interface/AccountsCDK.pm C4/InterfaceCDK.pm C4/Circulation/Renewals.pm C4/Interface/RenewalsCDK.pm C4/Accounts.pm C4/InterfaceCDK.pm C4/Circulation/Renewals.pm C4/Circulation/Issues.pm C4/Circulation/Main.pm C4/Reserves.pm C4/Accounts.pm C4/InterfaceCDK.pm C4/Circulation/Renewals.pm C4/Circulation/Issues.pm C4/Circulation/Main.pm C4/Circulation/Returns.pm C4/Search.pm C4/Reserves2.pm C4/Accounts.pm C4/InterfaceCDK.pm C4/Circulation/Renewals.pm C4/Circulation/Main.pm C4/Circulation/Issues.pm C4/Circulation/Borrower.pm C4/Circulation/Main.pm C4/Accounts.pm C4/InterfaceCDK.pm

2 3

Missing deleted* tables?
by Andrew Arensburger 06 Oct '02

06 Oct '02

If I understand correctly, the purpose of the deleted<foo> tables in the database is to provide a backup of any rows that may have been deleted from the <foo> table. That is, when an item is deleted, it isn't actually deleted, it just gets moved from the items table to the deleteditems table. That way, if something is deleted accidentally, it can (in principle) be restored. Is this correct so far? If so, it seems to me that there should be more deleted* tables, such as deletedbibliosubject and deletedbibliosubtitle, since the biblio table has "links" to various other tables, containing data that also should be saved in a backup table. Or am I on the wrong track here? -- Andrew Arensburger This message *does* represent the arensb(a)ooblick.com views of ooblick.com I play an important role as a bad example.

1 0

C4::Context
by Andrew Arensburger 05 Oct '02

05 Oct '02

Just to keep people informed (those who don't get CVS logs, at least): I've updated Koha to use C4::Context->dbh instead of &C4Connect throughout (RTFM C4::Context(3) for more details, or 'pod2text C4/Context.pm'). In a nutshell, $dbh = C4::Context->dbh returns a database handle, creating one if necessary. It is not necessary or even desirable to call $dbh->disconnect, since this handle is persistent, and gets closed when the script terminates. -- Andrew Arensburger This message *does* represent the arensb(a)ooblick.com views of ooblick.com This land is your land. This land is my land. So stay on your land.

1 0

Re: [Koha-devel] we've got a winner :-) => IMPORTANT
by Chris Cormack 03 Oct '02

03 Oct '02

On Fri, Oct 04, 2002 at 02:29:01PM +1000, Roger Buck said: > > Roger Buck wrote: > > > requires that we run six virtual hosts and a complicated file structure > > > with lots of duplication. This also means that I have spent a lot of > > > time evauating various options for file structure and configuration. > > > Chris Cormack wrote: > > Hmm I think you could get around this quite easily by setting an ENV > > variable in apache for your virtual hosts with the location of koha.conf in > > it. Then making Output.pm fetch it from the environment variable. > > We could set this up quite easily for you if you liked? > > > > Also with the use of Alias and ScriptAlias commands you could remove all > > duplication, see below for an example. > > Hmmm I think I know exactly what you're talking about... and I think I > understand how it works... but I still think there is a better option... > that works just as well for large installations as for small. > > > > > Especially with the move to templates, so there will be no more static html > > files > > OK... maybe I have misunderstood the current situation... or maybe the > templates will overcome some/all of this stuff: > > 1. Under current setup, I see no clear distinction between opac and > intranet file space - for example, I might be using public opac but > public opac is calling templates + some images and includes stored in > intranet file space? This "blurring" of the lines between Opac and > Intranet will become problematic - especially where security is > concerned... but maybe for knowing "what goes where" in general? > Right, and this is why we are moving them apart. Opac stuff lives in an opac area. Intranet stuff lives in another. > > 2. By the principle of least surprise, I would expect to be able to > install and run both opac and intranet web services without requiring > virtual hosts for either - A user should be able to integrate both > services seamlessly into an existing web server - all on a single port > at a single hostname.... as well as allowing for virtual hosts if > preferred. I don't think this is currently possible "out of the box". If > not, then why not? I think it can be done with a small amount of effort, the effort will smaller as the distinction between the opac and intranet becomes bigger. > > 3. The answer to #2 above may be that opac and intranet cgi scripts and > web pages require same virtual path in webspace even though they are > stored in physically separate locations, for example: > > On OPAC virtual host: > ScriptAlias /cgi-bin/koha/ /usr/local/www/koha/cgi-bin/opac/ > ------------^^^^^^^^^^^^^-----------------------------^^^^^^ > > On INTRANET virtual host: > ScriptAlias /cgi-bin/koha/ /usr/local/www/koha/cgi-bin/koha/ > ------------^^^^^^^^^^^^^-----------------------------^^^^^^ > > This is the only reason I can see that a separate virtual host is > required? Could be lots of reasons for a separate virtual host. In fact you may actual separate hosts. One reason is the sites live on different machines. Or on different ip numbers ... only one of which is externally routable. IE your intranet is actually an intranet. > > If true, then why is it better to have multiple virtual hosts - compared > with separate physical paths in config file. I don't see any security > benefits in using virtual servers for the above case? > > Am I on the wrong track here? :) > I think perhaps we are talking past each other :-) I want virtual hosts and separate paths for the files. At least between the opac and the intranet. If you have 5 opacs though, you shouldnt need five copies of the cgi-bin and templates. You will need 5 databases and 5 koha.conf files but only one set of the cgi's. So to try and summarise I want the opac and intranet systems to be standalone. Capable of being installed on separate machines, or on the same machine using separate hosts/ipnumbers/port numbers, or on the same machine using the same host and port. IE I want it all :-) Chris

2 2

Re: [Koha-devel] we've got a winner :-) => IMPORTANT
by Chris Cormack 03 Oct '02

03 Oct '02

On Fri, Oct 04, 2002 at 10:18:27AM +1000, Roger Buck said: > > > Andrew Arensburger wrote: > > > On the whole, I agree that /etc/koha.conf should contain as little > > > as possible. I'm just trying to come up with scenarios in which it would > > > make sense to put additional stuff in /etc/koha.conf. > > > > We run three independent Kohas on a single web server. This requires > > three separate copies of koha.conf (hardwired in Output.pm). This also > > requires that we run six virtual hosts and a complicated file structure > > with lots of duplication. This also means that I have spent a lot of > > time evauating various options for file structure and configuration. > > Hmm I think you could get around this quite easily by setting an ENV variable in apache for your virtual hosts with the location of koha.conf in it. Then making Output.pm fetch it from the environment variable. We could set this up quite easily for you if you liked? Also with the use of Alias and ScriptAlias commands you could remove all duplication, see below for an example. Especially with the move to templates, so there will be no more static html files Eg <VirtualHost koha1.something.org> ServerAdmin webmaster(a)something.org DocumentRoot /usr/local/www/koha/htdocs ScriptAlias /cgi-bin/ /usr/local/www/koha/cgi-bin/ ErrorLog /var/log/apache/koha1-error.log TransferLog /var/log/apache/koha1-access.log SetEnv KOHACONF /etc/koha1.conf </VirtualHost> <VirtualHost koha2.something.org> ServerAdmin webmaster(a)something.org DocumentRoot /usr/local/www/koha/htdocs ScriptAlias /cgi-bin/ /usr/local/www/koha/cgi-bin/ ErrorLog /var/log/apache/koha1-error.log TransferLog /var/log/apache/koha2-access.log SetEnv KOHACONF /etc/koha2.conf </VirtualHost> <VirtualHost koha3.something.org> ServerAdmin webmaster(a)something.org DocumentRoot /usr/local/www/koha/htdocs ScriptAlias /cgi-bin/ /usr/local/www/koha/cgi-bin/ ErrorLog /var/log/apache/koha1-error.log TransferLog /var/log/apache/koha3-access.log SetEnv KOHACONF /etc/koha3.conf </VirtualHost> All 3 using the same htdocs and same cgi-bin. Or you could have different docroots, but still make them all use the same images and includes eg Alias /images /usr/local/www/koha/htdocs/images Alias /includes /usr/local/www/koha/htdocs/includes I think that whatever we do, it still needs to be easy to have virtualhosts. The way koha is heading, there is definitely going to be the want/need to split services over many boxes. I can certainly see people wanting an opac server and an intranet server. So I think that the path we are going down, using HTML::Template and splitting the opac further away from the intranet code. Is a good one. I wouldnt like to see a solution that makes it easier for small libraries making it harder for big libraries. -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris(a)katipo.co.nz www.katipo.co.nz

2 1

(Fwd) Fwd: Free Online LC Authority Files
by Rosalie Blake 02 Oct '02

02 Oct '02

Kia ora Everybody, This came across my desk this morning.... Rosalie Blake Horowhenua Library Trust >>> Grace-Ellen McCrann <gemscot(a)yahoo.com> 30/09/2002 00:28:51 >>> 29 September 2002 Dear Everybody, This past week LC has begun offering free online access to their authority files at: http://authorities.loc.gov/ You can search, display and/or download LC authority records in MARC 21. Lots of good stuff...and the price is certainly right! Kind regards, Grace-Ellen Grace-Ellen McCrann Chief, Government Documents Division The City College of New York Cohen Library, Room 2/305 138th Street & Convent Avenue New York, NY 10031 (212) 650 5073 gemscot(a)yahoo.com _______________________________________________________ ____________ -------------- This message has come via the NZ-Libs email discussion list. To unsubscribe, send to listar(a)vuw.ac.nz the message text "unsubscribe nz-libs". More details at http://www.vuw.ac.nz/~agsmith/ssbubl/currawar/nzlibs.html -------------- ------- End of forwarded message -------

1 0

Templated opac code
by Finlay Thompson 01 Oct '02

01 Oct '02

Hi everyone again. Some of the confusion regarding templating has been caused by the fact that it is all in the rel-1-2 branch As the new fully templated opac, complete with Authenticated User access, will be ready very shortly. Unless someone has a problem, I will merge it into main branch. so that it can go into the 1.3 release. Finlay

1 0