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

PODs online
by Pat Eyler 11 Oct '02

11 Oct '02

I've put the PODS online. (Thanks Andrew, Paul, and crew for writing them). I'm currently building them out of cvs (updated nightly) every morning (~0430 EDT). A couple of them have some issues (bad POD). If you want to go take a look, they're at: http://www.kohalabs.com/resources/pod/ -pate

2 5

koha on macos X
by David Strainchamps 11 Oct '02

11 Oct '02

Hi every one, I'm david, a new in koha and with little expérience in perl programming I've download the cvs and find little problem. I'm on macos X I want just to say that the template are not only in koha/koha-tmpl and i found intranet-main.tmpl in catalogue altough it would be found in koha-tmpl Other litlle problem adbooks.pl don't run with me see the file error_log attached I'm working "langsam" "lentement" "not speed" on templating the admin scripts. I'm on branches.pl coze i'm beginner in perl David Scalar found where operator expected at /Library/Perl/C4/Circulation/Circ2.pm line 1752, near ") $sth" (Missing operator before $sth?) syntax error at /Library/Perl/C4/Circulation/Circ2.pm line 1752, near ") $sth" Compilation failed in require at /Library/WebServer/CGI-Executables/koha/acqui.simple/addbooks.pl line 39. BEGIN failed--compilation aborted at /Library/WebServer/CGI-Executables/koha/acqui.simple/addbooks.pl line 39. [Fri Oct 11 13:16:54 2002] [error] [client 127.0.0.1] Premature end of script headers: /Library/WebServer/CGI-Executables/koha/acqui.simple/addbooks.pl

2 1

RE: [Koha-devel] Perl Bundle
by Christensen, David A. (CHT) 10 Oct '02

10 Oct '02

I've been successfully using the 'new_from_usmarc( $marcblob )' in MARC::Record for quite a while.... -David > -----Original Message----- > From: Mike Mylonas [SMTP:dragon28@ihug.co.nz] > Sent: 2002-Sep-30 12:03 AM > To: koha-devel(a)lists.sourceforge.net > Subject: [Koha-devel] Perl Bundle > > I am just about to upload version 0.02 of the Bundle::KohaSupport which > will include MARC::Record, and its dependancies, to assist those working > with 1.3.x > > Can anyone (Paul or Steve) confirm that the issue that Paul raised ... > > --begin quote-- > UNLESS steve has a good new, we can't use MARC::Record for instance : we > had to modify it because the official release don't allow reading of a > MARC record from a variable, but only from a file. The 4 lines added to > enable reading from a variable were refused by MARC::Record maintainer, > arguing we can save our variable to a file > --end quote-- > > I will still make the change to include MARC::Record but can replace the > release quickly with one without. > > Also I would appreciate it if people can test the Bundle and fire any > problems/issues etc into the Koha bugzilla > > Cheers > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/koha-devel

1 0

koha 1,4, templating and css
by paul POULAIN 10 Oct '02

10 Oct '02

Hi, Finlay, a few days ago, said : "However, there is no reason we can have heaps of CSS in the templated koha. It just goes into files that are read in through <TMPL_INCLUDE NAME="stylesheet"> tags." I agreed, but, i'm less sure now... I explain : css has 2 goals : one important, and one less. * the 1st goal, as finlay said, is to separate content from style. The <TMPL_INCLUDE> solution respects this. * the 2nd goal is to lower data traffic between server and client : the html does not contain many "style tags" as they are all in the css, and the css, when extenal, is CACHED, and passed only once to the client ! If we use css inclusion in htm file, we loose the 2nd goal. But... it we use a <link rel="stylesheet" type="text/css" href="style.css">, we must put the style sheet in htdocs scope, not in cgi. Thus, we need a /template/<theme>/<lang> in both cgi and htdocs. what do you think of this ? do you have a problem with having a /template... in htdocs as well as in cgi-bin ? do you think we can forget "data traffic optimization" ? I *vote* for the <link rel="stylesheet" type="text/css" href="style.css"> solution, having a good traffic optimization and a /template/... in htdocs. I know that *chris* has the *same* opinion (irc) Note anyway I agree that a theme/language should use always the same css. Maybe, every language for a theme will use the same ! Note also i'm working on default/en/style.css, so expect it soon on cvs ! It will respect completly the look of the actual koha, so migration from non-css to css can be done on the fly. -- Paul

8 15

RE: KOHA Questions (fwd)
by Pat Eyler 09 Oct '02

09 Oct '02

Here are the answers I've sent back. I thought you'd all like to see them. I appreciate everyone who stepped up to answering the bits that I had no clue about. -pate ---------- Forwarded message ---------- Date: Wed, 9 Oct 2002 19:20:28 -0400 (EDT) From: Pat Eyler <pate(a)eylerfamily.org> Subject: RE: KOHA Questions Glen, because Koha is an Open Source project and not a vendor, some of the answers below are a bit vague. There are a number of vendors who are selling support and development for Koha (or who are planning to), and I can point you at some of them if you'd like. I understand that you may want to do some or all of the development work yourselves, that would be fine as well. The Koha development community would certainly be happy to help in any way that we can. If you have any further questions, or need clarification, please feel free to contact me. thanks, -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org 1 -- Which operating system, or choice of systems, does the proposed library automation system run on? Koha runs best on linux, but has been installed on (at least) FreeBSD and NT2000. It should be able to run on other POSIX OSes that have Perl5, MySQL, and Apache running on them. 2 -- Is system administration done with command lines or a graphical module? We should see it. Systems Administration happens at two levels. The library system is mostly exposed via a web interface (or commandline or Perl/Tk interfaces if you prefer). Administration of the underlying system and components is traditionally performed via the command line. There exist commandline options to manage the library system and graphical options to manage the lower layer pieces as well. 3 -- What is the backup utility? Does it use tapes? Koha relies on the OS level tools to handle back ups. backups could be done to tape, DLT, CD-ROM, or (via replication) to one or more other systems. 4 -- Does the system have its own file and disk maintenance procedures? If so, how are they performed? No, Koha relies on typical Linux/Unix tools, processes, and procedures. 5 -- What administrative functions or upgrades require the system to be off-line, and for how long? Upgrading the system could be done by taking the system off-line and performing the upgrade, or by swapping installed servers. In the first case, the upgrade would require up to an hour of downtime, in the second, you should be able to swap the systems in under 15 minutes. Patches and similar, minor upgrades do not require any system downtime. 6 -- Is there a backup module for circulation in case the system is down? Koha can be run in stand-alone mode (a server running on the local system), this has been done to create 'bookmobile' systems. 7 -- Describe the way customer support works, what it covers, and hours of service. Koha is an open source project. As such, unpaid volunteers provide support via email or irc. There are a number of vendors who would be willing to provide higher levels of service. You would need to contact those vendors for specifics. If you are interested, there is a list of such vendors at http://www.koha.org/installation/support.html or by email to the kohabiz(a)eylerfamily.org mailinglist. 8 -- What is the indexing capability for the catalog? How many indexes can we have? Can they be customized? Because the system is open source, you can customize it to whatever degree you desire. 9 -- Describe the capacity for integrating selfcheck machines with the system. Is it SIP1/SIP2/NCIP compliant? We don't currently have a self check system in place. Nelsonville Public Library has expressed interest in sponsoring NCIP development work. We've also heard interest from 3M in developing the support for their self-checkout system for Koha if there were libraries interested using the hardware on Koha. 10 -- What report writing capability does the system have? Koha does not ship with a report writer. Reports could be written with any tool that can interact with MySQL. Perl and DBI are know to work well. 11 -- What "canned" reports are available? There are curretnly very few canned reports that come with Koha. Because the code is open, and the DB is exposed to the standard Perl-DBI interface, writing new reports would be an easy extension. 12 -- Is there an API available? Can we develop applications that can directly access the database? Yes, there is an API available. We encourage you to develop new feature within Koha, or as adjuncts to it. If you choose to do so, the license allows you to redistribute your work (and we encourage you to do so). 13 -- Is there a function for electronic ordering, such as from Baker and Taylor? Does B&T support your ordering module? This is not a part of our current acquisitions system. It would be a relatively easy feature to add though. 14 -- What flexibility is there for customizing the catalog? Can the catalog engine search external databases? The catalog is completely customizable. As written, it is built around the MARC standard(s) (starting with the development version, currently at version 1.3.0). It is already capable of supporting both MARC21 and UNIMARC. 15 -- Is the system client-server or web based? Koha is a web based application. (There is still a text based front-end though.) 16 -- What is the capacity for e-mail functions, including e-mail notices? This functionality is currently being added, and should be present in the 1.2.3 release. 17 -- Can the system integrate library fines with external payment interfaces (library cards, etc.)? This function doesn't currently exist, but could be added. 18 -- Which RFID vendors have successfully integrated with your system? There are no libraries using Koha with RFID devices currently. If the RFID device can be made to work with Linux (or your chosen OS) it should be possible to integrate it into Koha. 19 -- Can receipt printers work with the system? Yes. 20 -- Have you converted DRA Classic sites in the past? Describe your conversion process. What data can you *not* convert? Again, this is a question to ask a Vendor working with Koha. In general, if the data can be extracted from your DRA system, it can be loaded into Koha's DB. Particularily esoteric data might require the addition of new tables. 21 -- Can your system work with Epixtech's URSA module for inter-library loan? Koha does not currently do this. 22 -- Do you provide an integrated point of sale module? There is a system for managing fine payments and a till. 23 -- What functions can our public do from home via our catalog -- pay fines? renew items? place requests? renew cards? This is very customizable. We'd recommend that you not do things that would require authentication (renewing cards and the like), but there are many services that carry low risk and would be ideal for home based users. Paying fines from home would require an interface to PayPal or a merchant account, as well as some development work. 24 -- Does the catalog have multi-lingual support? This is currently being developed. The French and German development groups are particularily involved in this effort. 25 -- What are the options, or lack of, regarding database privacy (reading records of the public, retrospective history, etc.)? This is an area that would be open to development. Some thoughts we've had are: keeping full histories (popular outside the US), keeping anonymized records, or keeping only records that patrons specifically request. 26 -- Is there support for access via hand-helds? Handlhelds providing 802.11b support and a web browser would be able o interface with the system as is. Other forms of access would require some development effort. 27 -- What is the database platform? Proprietary? Oracle? Informix? SQL? Something else? Koha normally runs on MySQL, an open source SQL RDBMS. There is work underway to add support for PostgreSQL as well. 28 -- Can customized fields be added to either item or patron records? Yes, the DB Schema is completely open. You can make any changes or additions that you want. 29 -- What flexibility is there for searching item and patron records? Can additional item and patron fields be made searchable? Yes, any fields could be made searchable. Because the code is open, you can amek any changes you desire. 30 -- Can the system store content (not just indexing) for digital materials, photographs, e-books, digital audio? This functionality could be added to Koha. 31 -- Can staff get real-time statistics on demand? Reports would need to be written and exposed to the staff via cgi. 32 -- Is there any way for users to get automatic bibliographies on request? Reports would need to be written and exposed to the staff via cgi. 33 -- Is there any capacity for debit interfaces with functions such as printing? A module would need to be developed to do this. 34 -- What kind of hardware do you recommend? Does your configuration include RAID? Koha runs quite well on off the shelf PC grade hardware. For added stability, it would be worth investing in Server Class systems featuring redundant power supplies and RAID. For truly redundant systems, a cluster of Server class systems could be used with the offline boxes providing Searching and related OLAP work, while the online system does circulation and other OLTP work. 35 -- What database redundancy is built into the system, in case a disk is lost or corrupted? Koha depends on the features of Linux and MySQL which include: RAID, journaling files systems, and Database replication. 36 -- What kind of support do you have for bookmobile operation, eg. a cache of the whole database changed every day? See Question 6, above. 37 -- Is there support for cover pages, excerpts, etc., such as we can purchase from Syndetic? This functionality could be added. 38 -- Can the public place requests for titles which are on order? This functionality could be added. 39 -- Is there integrated selector management -- that is, when you select a title from a database such as OCLC, can it be loaded into the system and ordered? This functionality could be added. 40 -- How is access managed to OCLC? We don't currently provide access to OCLC. 41 -- How are long overdue items managed -- patron notices, credit bureau reports, masking from the database, etc.? Does the capacity exist to transfer these items into an auxiliary database? Patrons are given notices and a hold is put on their account so that if they come in in the meantime it flags. A report is run and the statement can be sent to a credit bureau. Items show up in the OPAC if they are not "given up on" with a last seen date, or they are marked Lost. If they are lost they don't show up in the OPAC, but do show up in the Librarians intranet. I think that they are "purged" from time to time at library request, and they get shifted to a "deleted" table, in case they need to be recovered later. Additional reports could be written to manage long overdue items. These reports and others could be run from a replicated copy of the online database for performance reasons, or could be scheduled to run as batch jobs during low-traffic periods. 42 -- Explain the hierarchical nature of database locations (system, agencies, departments, or whatever). Our Virtual Bookshelf should allow items to be categorized into a flexible heirarchy. 43 -- How are item statuses used? Can they be converted from DRA Classic to the new system? Item status can be used to control the display of an item. Data pulled from DRA classic could be imported and used within Koha. 44 -- What is the procedure for processing lost items? This is a manual process at present, but it could be automated. 45 -- What kind of transaction statistics are kept for items? For patrons? Koha can keep all of them. Alternatively, the data could be discarded, or anonymized in whole or in part. 46 -- How does licensing work? How are fees determined? Koha is available under the Gnu General Public License. There are no fees to license or use Koha. 47 -- Can the system handle consortia? How does this affect licensing fees? Yes, Koha can be used for consortia. As there are no licensing fees, there is no effect. 48 -- What can be controlled by the systems calendar (eg. days when items are not due, fines not charged, etc.)? Currently this is controlled manually, but could be automated if desired. 49 -- What kind of patron delinquency statuses are available? Can patron statuses be converted from DRA Classic? Koha can place a temporary bar on borrowing if people owe more than a pre determined amount in fines, and can permanently disqualify a patron. There are also Child and guarantor relationships (children must "belong" to an adult), and other categories of user who have different fine privliges . Again, additional or different statuses could be used. 50 -- Does the catalog allow searching by item (not bibliographic) call numbers? This functionality could be added. 51 -- What is the hierarchy of the bibliographic database (bibliographic records, call number records, item records)? Koha uses three levels of records: biblios - everything with the same content has the same biblio (i.e. ignores what media, publisher, etc.) biblioitem - everything with the same media, publisher, etc. has the same biblioitem (ignores different copies of the same book etc.) item - what actually gets loaned out (so, e.g., has a barcode, can be put on a shelf, etc) 52 -- What is the system of classifications for materials (material codes)? Can selfcheck checkouts be limited to specified item classifications? Koha supports different lending policies depending on item classification. This could be broadened to encompass patron classification as well. Assuming selfcheck checkouts were added to Koha, these could be controlled in the same manner. 53 -- Can the system allow automatic charges to patron records as certain classes of items are checked out? Can this feature be used with the selfcheck? This functionality could be added. (Our Virtual Bookshelf feature would be a good way to support it.) 54 -- Is it possible to set up multiple databases within the system? Yes, with our Virtual Bookshelf feature. 55 -- Is there a text catalog that can be used for modem access (for people who are not yet on the Internet)? Yes. 56 -- Does the system allow tracking between patron categories and item categories for circulation statistics? This functionality could be added. The data is already in the system, so it would be a matter of writing a report. 57 -- Can fine records for patrons be converted to your system from DRA Classic? If the data can be extracted, it can be converted.

3 2

last couple of niggling questions
by Pat Eyler 09 Oct '02

09 Oct '02

Thanks to Rachel, it's down to two questions: 43 -- How are item statuses used? Can they be converted from DRA Classic to the new system? (I assume that this refers to 'lost', 'shelved', 'on hold', 'checked in', or 'on loan'. I really have no idea how these would be used in practice though. Any thoughts?) 51 -- What is the hierarchy of the bibliographic database (bibliographic records, call number records, item records)? (Paul, ?!?!?!?HELP!?!?!?!) thanks, -pate

2 1

questions for Kha
by Pat Eyler 09 Oct '02

09 Oct '02

Okay, I've gotten most of the questions answered ... I'm looking for some help though. If anyone could step up and handle 43-45, 48-49, and/or 51, I'd really appreciate it. Responses to the wiki: http://www.saas.nsw.edu.au/wiki/index.php?page=QuestionsPosed or in private email (please paste in just the question you're answering) would both be appreciated. (the wiki is probably the better way.) thanks, -pate --------------------Q&A-------------------- 1 -- Which operating system, or choice of systems, does the proposed library automation system run on? Koha runs best on linux, but has been installed on (at least) FreeBSD and NT2000. It should be able to run on other POSIX OSes that have Perl5, MySQL, and Apache running on them. 2 -- Is system administration done with command lines or a graphical module? We should see it. Systems Administration happens at two levels. The library system is mostly exposed via a web interface (or commandline or Perl/Tk interfaces if you prefer). Administration of the underlying system and components is traditionally performed via the command line. There exist commandline options to manage the library system and graphical options to manage the lower layer pieces as well. 3 -- What is the backup utility? Does it use tapes? Koha relies on the OS level tools to handle back ups. backups could be done to tape, DLT, CD-ROM, or (via replication) to one or more other systems. 4 -- Does the system have its own file and disk maintenance procedures? If so, how are they performed? No, Koha relies on typical Linux/Unix tools, processes, and procedures. 5 -- What administrative functions or upgrades require the system to be off-line, and for how long? Upgrading the system could be done by taking the system off-line and performing the upgrade, or by swapping installed servers. In the first case, the upgrade would require up to an hour of downtime, in the second, you should be able to swap the systems in under 15 minutes. Patches and similar, minor upgrades do not require any system downtime. 6 -- Is there a backup module for circulation in case the system is down? Koha can be run in stand-alone mode (a server running on the local system), this has been done to create 'bookmobile' systems. 7 -- Describe the way customer support works, what it covers, and hours of service. Koha is an open source project. As such, unpaid volunteers provide support via email or irc. There are a number of vendors who would be willing to provide higher levels of service. You would need to contact those vendors for specifics. If you are interested, there is a list of such vendors at http://www.koha.org/installation/support.html or by email to the kohabiz(a)eylerfamily.org mailinglist. 8 -- What is the indexing capability for the catalog? How many indexes can we have? Can they be customized? Because the system is open source, you can customize it to whatever degree you desire. 9 -- Describe the capacity for integrating selfcheck machines with the system. Is it SIP1/SIP2/NCIP compliant? We don't currently have a self check system in place. Nelsonville Public Library has expressed interest in sponsoring NCIP development work. We've also heard interest from 3M in developing the support for their self-checkout system for Koha if there were libraries interested using the hardware on Koha. 10 -- What report writing capability does the system have? 11 -- What "canned" reports are available? There are curretnly very few canned reports that come with Koha. Because the code is open, and the DB is exposed to the standard Perl-DBI interface, writing new reports would be an easy extension. 12 -- Is there an API available? Can we develop applications that can directly access the database? Yes, there is an API available. We encourage you to develop new feature within Koha, or as adjuncts to it. If you choose to do so, the license allows you to redistribute your work (and we encourage you to do so). 13 -- Is there a function for electronic ordering, such as from Baker and Taylor? Does B&T support your ordering module? This is not a part of our current acquisitions system. It would be a relatively easy feature to add though. 14 -- What flexibility is there for customizing the catalog? Can the catalog engine search external databases? The catalog is completely customizable. As written, it is built around the MARC standard(s) (starting with the development version, currently at version 1.3.0). It is already capable of supporting both MARC21 and UNIMARC. 15 -- Is the system client-server or web based? Koha is a web based application. (There is still a text based front-end though.) 16 -- What is the capacity for e-mail functions, including e-mail notices? This functionality is currently being added, and should be present in the 1.2.3 release. 17 -- Can the system integrate library fines with external payment interfaces (library cards, etc.)? This function doesn't currently exist, but could be added. 18 -- Which RFID vendors have successfully integrated with your system? There are no libraries using Koha with RFID devices currently. If the RFID device can be made to work with Linux (or your chosen OS) it should be possible to integrate it into Koha. 19 -- Can receipt printers work with the system? Yes. 20 -- Have you converted DRA Classic sites in the past? Describe your conversion process. What data can you *not* convert? Again, this is a question to ask a Vendor working with Koha. In general, if the data can be extracted from your DRA system, it can be loaded into Koha's DB. Particularily esoteric data might require the addition of new tables. 21 -- Can your system work with Epixtech's URSA module for inter-library loan? Koha does not currently do this. 22 -- Do you provide an integrated point of sale module? There 23 -- What functions can our public do from home via our catalog -- pay fines? renew items? place requests? renew cards? This is very customizable. We'd recommend that you not do things that would require authentication (renewing cards and the like), but there are many services that carry low risk and would be ideal for home based users. Paying fines from home would require an interface to PayPal or a merchant account, as well as some development work. 24 -- Does the catalog have multi-lingual support? This is currently being developed. The French and German development groups are particularily involved in this effort. 25 -- What are the options, or lack of, regarding database privacy (reading records of the public, retrospective history, etc.)? This is an area that would be open to development. Some thoughts we've had are: keeping full histories (popular outside the US), keeping anonymized records, or keeping only records that patrons specifically request. 26 -- Is there support for access via hand-helds? Handlhelds providing 802.11b support and a web browser would be able o interface with the system as is. Other forms of access would require some development effort. 27 -- What is the database platform? Proprietary? Oracle? Informix? SQL? Something else? Koha normally runs on MySQL, an open source SQL RDBMS. There is work underway to add support for PostgreSQL as well. 28 -- Can customized fields be added to either item or patron records? Yes, the DB Schema is completely open. You can make any changes or additions that you want. 29 -- What flexibility is there for searching item and patron records? Can additional item and patron fields be made searchable? Yes, any fields could be made searchable. Because the code is open, you can amek any changes you desire. 30 -- Can the system store content (not just indexing) for digital materials, photographs, e-books, digital audio? This functionality could be added to Koha. 31 -- Can staff get real-time statistics on demand? Reports would need to be written and exposed to the staff via cgi. 32 -- Is there any way for users to get automatic bibliographies on request? Reports would need to be written and exposed to the staff via cgi. 33 -- Is there any capacity for debit interfaces with functions such as printing? A module would need to be developed to do this. 34 -- What kind of hardware do you recommend? Does your configuration include RAID? Koha runs quite well on off the shelf PC grade hardware. For added stability, it would be worth investing in Server Class systems featuring redundant power supplies and RAID. For truly redundant systems, a cluster of Server class systems could be used with the offline boxes providing Searching and related OLAP work, while the online system does circulation and other OLTP work. 35 -- What database redundancy is built into the system, in case a disk is lost or corrupted? Koha depends on the features of Linux and MySQL which include: RAID, journaling files systems, and Database replication. 36 -- What kind of support do you have for bookmobile operation, eg. a cache of the whole database changed every day? See Question 6, above. 37 -- Is there support for cover pages, excerpts, etc., such as we can purchase from Syndetic? This functionality could be added. 38 -- Can the public place requests for titles which are on order? This functionality could be added 39 -- Is there integrated selector management -- that is, when you select a title from a database such as OCLC, can it be loaded into the system and ordered? This functionality could be added 40 -- How is access managed to OCLC? We don't currently provide access to OCLC. 41 -- How are long overdue items managed -- patron notices, credit bureau reports, masking from the database, etc.? Does the capacity exist to transfer these items into an auxiliary database? Reports could be written to manage long overdue items. These reports and others could be run from a replicated copy of the online database for performance reasons, or could be scheduled to run as batch jobs druing low-traffic periods. 42 -- Explain the hierarchical nature of database locations (system, agencies, departments, or whatever). Our Virtual Bookshelf should allow items to be categorized into a flexible heirarchy. 43 -- How are item statuses used? Can they be converted from DRA Classic to the new system? 44 -- What is the procedure for processing lost items? 45 -- What kind of transaction statistics are kept for items? For patrons? 46 -- How does licensing work? How are fees determined? Koha is available under the Gnu General Public License. There are no fees to license or use Koha. 47 -- Can the system handle consortia? How does this affect licensing fees? Yes, Koha can be used for consortia. As there are no licensing fees, there is no effect. 48 -- What can be controlled by the systems calendar (eg. days when items are not due, fines not charged, etc.)? 49 -- What kind of patron delinquency statuses are available? Can patron statuses be converted from DRA Classic? 50 -- Does the catalog allow searching by item (not bibliographic) call numbers? This functionality could be added. 51 -- What is the hierarchy of the bibliographic database (bibliographic records, call number records, item records)? 52 -- What is the system of classifications for materials (material codes)? Can selfcheck checkouts be limited to specified item classifications? This functionality could be added. (Our Virtual Bookshelf feature would be a good way to support it.) 53 -- Can the system allow automatic charges to patron records as certain classes of items are checked out? Can this feature be used with the selfcheck? This functionality could be added. (Our Virtual Bookshelf feature would be a good way to support it.) 54 -- Is it possible to set up multiple databases within the system? Yes, with our Virtual Bookshelf feature. 55 -- Is there a text catalog that can be used for modem access (for people who are not yet on the Internet)? Yes. 56 -- Does the system allow tracking between patron categories and item categories for circulation statistics? This functionality could be added. 57 -- Can fine records for patrons be converted to your system from DRA Classic? If the data can be extracted, it can be converted.

1 0

Re: [Koha-devel] koha 1,4, templating and css
by paul POULAIN 09 Oct '02

09 Oct '02

Dorian Meid wrote: >We don't need a <theme>/<lang>/ structure in the cgi-tree. >The scripts in the cgi-tree are the same for all themes and languages. >We allready have a <theme>/<lang>/ structure in the >htdocs(serverroot)-tree. > ??? we said a few days ago that it was a bad idea to put templates in html path, they should be in cgi-bin path for security reasons. But i can't find the mail where we spoke of this, so maybe another opinion ? finlay when he comes back ? I don't see any theme/lang structure in the serverroot tree neither in 1.2 nor in main branch. -- Paul

2 2

50 questions
by Pat Eyler 09 Oct '02

09 Oct '02

I didn't get around to answering the questions at: http://www.saas.nsw.edu.au/wiki/index.php?page=QuestionsPosed I'll be answering them today and sending them off at about 3PM PDT my time (-0700). If you've had any last minute bursts of insight, I'd encourage you to put them up there. thanks, -pate

1 0

Templating design
by Finlay Thompson 08 Oct '02

08 Oct '02

Hi Everyone, It seems that everyone had a email conversation about the way templating is being done in koha. I have been working on templating the opac. Let me explain what I have done, which is not to say that it is the right way :-) Firstly I should point out that I have been developing on the rel-1-2 branch, but will probably merge this into the 1.3 release. If you want to go and check it out go to http://opacdev.katipo.co.nz you can login using user:pword = frank:frank or finlay:finlay CVS: All the templates are going into the koha-tmpl tree of cvs. under this root we have two sub-branches intranet-tmpl/ and opac-tmpl/ eveything onder there should be installed in koha/intra/htdocs/ and koha/opac/htdocs/ respectivly. And then we have the structure: <theme>/<lang>/<scriptname>.tmpl I suggest that we try hard to keep the templates and scripts with the same names..... includes and images go under the <theme>/<lang>/ directory..... An example: The opac-search.pl script presents the search form in the opac. see: http://opacdev.katipo.co.nz/cgi-bin/koha/opac-search.pl it calls the opac-search.tmpl template which in this instance is found in the default/en/ theme and language. There is an include at the top: cat-top.inc and this is found in default/en/includes/cat-top.inc all the images in the templates are prefixed by the HTML::Template tag: <TMPL_VAR NAME="themelang"> eg. src="<TMPL_VAR NAME='themelang'>/images/search-button.gif" This template variable is automatically passed to includes and is automatically loaded into the template by the template loading subroutine..... Template loading: The relevant code in opac-search.pl is: use C$::Output; my $template = gettemplate("opac-search.tmpl", "opac"); The method gettemplate handles eveything about choosing theme and lang settings and finding a template etc. It then loads the "themelang" variable and returns the template. The "opac" string is simply to switch to the opac tree. however in the future this gettemplate method could perhaps be made to take a hash of options? Note: there is another candidate for the gettemplate code that Dorian wrote. His subroutine is called "pathtotemplate" and does many of the same things, except it doesnt actually intialise the template. I think that keeping the template intialising code to one line is a good idea, and I dont think there is any loss of flexibility if I allow gettemplate to pass a hash of options to the HTML::Template module. I like what andrew said with regard to something else the other day: "This way, simple scripts remain simple, and complex scripts become possible." That is a very good principle. As most of the time the scripts have one template associated, and no extra options on the template, the above one-liner will be enough. Anyway, I hope this has clarified what I have been up to. I will update the reading material on: http://koha.org/contribute/templating/ Finlay

9 18