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

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

RE: [Koha-devel] question about templating and directory structure
by Eyler, Patrick 01 Oct '02

01 Oct '02

> -----Original Message----- > From: paul POULAIN [mailto:paul.poulain@free.fr] > Sent: Tuesday, October 01, 2002 8:03 AM > To: koha-devel(a)lists.sourceforge.net; Finlay Thompson > Subject: [Koha-devel] question about templating and directory > structure > > I'm working a little on templates, for MARC support, and i've some > problems. > > How templates are supposed to be organised ? > I thought it was : > includes/templates/[theme_name]/* > > but i saw some posts about [language]/[theme_name]/* I think that we need to include the language identification above the theme identification. includes/templates/[language]/[theme_name] makes sense to me. > > and today, finlay released files into > koha/koha-tmpl/intranet-tmpl/default/en/* I think this is broken WRT previous discussions. It seems like thes should be includes/templates/en/default/intranet/* If I'm wrong, please let me know. > > I begin to be lost, and think that before beginning translations > and/or > releasing templated koha we should say definetly where are > templates, > and modify move file accordingly... > > to end, i think we should spend some time to merge 1.2 templating > stuff > to main branch too... This is certainly true. Does anyone want to step up to running the merge? -pate > -- > Paul > > > > ------------------------------------------------------- > This sf.net email is sponsored by: DEDICATED SERVERS only $89! > Linux or FreeBSD, FREE setup, FAST network. Get your own server > today at http://www.ServePath.com/indexfm.htm > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/koha-devel

4 5

Re: [Koha-devel] Repetitious behavior repeatedly
by paul POULAIN 01 Oct '02

01 Oct '02

Nathan Gray wrote: >I believe what you are considering is object-oriented programming, >which can make a lot of sense, if you build your objects correctly. >You decide which information is allowed to be stored in the object, >and which methods (functions) will be handled internally by the >object. Then you just pass around one variable, usually called >'$self'. When you want a dbh, you could run: > > my $dbh = $self->dbh; > That's it ! Great idea. Thus, there will be only a few things to change in koha. Every script starts with my $param_object = buildparam->new(); Every C4 sub is called with $result = C4Function($param_object,$other_param1, $other_param2,...); And every C4 sub needs only to have 2 lines rewritten : sub MySub(); my ($param,$other1, $other2) = @_; my $dbh = $param->dbh; instead of sub MySub(); my ($dbh,$other1, $other2) = @_; If in a C4 sub we need an other parameter, we can use : my $HashOfStopWord = $param->stopwordlist(); and work with HashOfStopWord. >The 'dbh' method would know how to get a new database handle, or would >return the existing one, if it has already made a connection. > Very nice idea too. With this one, we fill, for example stopword list only when ->stopwordlist() is called : no unuseful DB readings. Note that the DB handle is so necessary that i think this one should always be created when object is created. >You could very easily create a 'prepare' method in self, that would in >turn run 'prepare' on the dbh. > sub prepare { > my $self = shift; > my $query = shift || return; > my $dbh = $self->dbh || return; > my $sth = $dbh->prepare($query); > unless ($sth) { > warn $dbh->errstr; > } > return $sth; > } >Each method would handle its own error handling, when appropriate. >Adding methods for 'param' and 'stopwords' would also be really easy. >Let me know if you need any help, if you decide to go this route. I >now write most of my code in an object-oriented style, because I find >it much easier to keep track of where everything is. Then you can >also inherit methods from other objects, and all sorts of fun stuff >(perhaps down the road a ways). > I'm very poor at Perl-OOP, so any help is greatly welcomed ;-) Give an object with db handle and stopwords management, i'll copy/paste for other tables if you don't do. Don't you have a cvs account on sourceforge ? >kolibrie > I think we've got a winner at Perl Programming... (twice winning in 1 week. Kudos Nathan ;-) ) -- Paul

2 2

question about templating and directory structure
by paul POULAIN 01 Oct '02

01 Oct '02

I'm working a little on templates, for MARC support, and i've some problems. How templates are supposed to be organised ? I thought it was : includes/templates/[theme_name]/* but i saw some posts about [language]/[theme_name]/* and today, finlay released files into koha/koha-tmpl/intranet-tmpl/default/en/* I begin to be lost, and think that before beginning translations and/or releasing templated koha we should say definetly where are templates, and modify move file accordingly... to end, i think we should spend some time to merge 1.2 templating stuff to main branch too... -- Paul

1 0