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

template system abuse
by Pierrick LE GALL 13 Apr '06

13 Apr '06

Hi koha-devel, Having worked on several intranet template, I've seen things that make me think we sometimes abuse of the HTML::Template toolkit. Apart from the pagination bar I added recently, I propose 2 examples: 1. URL creation =============== We want an URL like the following: "script.pl?key1=value1&key2=value2" To achieve this, I've seen : href="?firstkey=firstval&=&" (everything on a single line, of course... enjoy the unreadability of 345 characters per line) I really don't understand what we gain by building the URL in the template... while we could do this beautifuly in Perl code before sending to template: $template->param( url => $scriptname.'?'. .join( '&', map { $_->{key}.'='.$_->{val} } @field_data ), ); and in template: href="" 2. "selected" option in SELECT ============================== Each option of an HTML SELECT can be selected or not. Localization mecanism forbids to have a TMPL_IF inside the <option> tag. So we need something like:   <option value="" selected="selected"></option>  <option value=""></option>   The risk of typo is not negligible, the template can become huge with many options (see koha/koha-tmpl/intranet-tmpl/prog/en/circ/circulation.tmpl to understand what I mean). Couldn't we simply have  <option value="" ></option>  With in Perl script: selected => (condition ? ' selected="selected"' : '') My conclusion... In my opinion, template system is useful for customization. The examples above are no customization, they make templates heavier, less readable... harder to customize. Do I miss something or do we really need complicated templates on given examples? Bye, -- Pierrick LE GALL INEO media system

3 6

Template Development
by Kyle Hall 13 Apr '06

13 Apr '06

Hey All, Is there any way to find out what branch an intranet browser is set to from any page? I tried using TMP_VAR NAME="branchname" but it is only accessible from circulation.tmpl. Thanks, Kyle

4 4

Investigations on Perl, MySQL & UTF-8
by Pierrick LE GALL 13 Apr '06

13 Apr '06

Hi koha-devel, Because the story of Perl, MySQL, UTF-8 and Koha is becoming more and more complicated, I've decided to start my tests outside of Koha or any web server. I wanted to check that Perl and MySQL could communicate with UTF-8 data. What I did : 1. copy some UTF-8 strings from http://www.columbia.edu/kermit/utf8-t1.html paste into a UTF-8 text file utf8.txt (open/past in UTF-8 console, with Vim having :set encoding=utf-8) 2. create a UTF-8 database with a simple table having a TEXT field $ mysql --user=root --password=xxx mysql> CREATE DATABASE `utf8_test` CHARACTER SET utf8; mysql> connect utf8_test mysql> create table strings (id int, value text); mysql> quit (no need to set connection character set to utf-8 in that case, default latin1 is fine) Note: my MySQL server is latin1... $ mysql --user=root --password=xxx utf8_test mysql> status Server characterset: latin1 Db characterset: utf8 Client characterset: latin1 Conn. characterset: latin1 mysql> set names 'UTF8'; mysql> status Server characterset: latin1 Db characterset: utf8 Client characterset: utf8 Conn. characterset: utf8 3. write and execute a Perl script which reads the UTF-8 text file, insert UTF-8 strings into database, retrieve UTF-8 strings from database, print UTF-8 strings to STDOUT. See details in attached file readfile_insertdb.pl. Important note: "set names 'UTF8';" is mandatory. Everything is *working fine*. My output is in UTF-8, I'm 100% sure of it. DBD::mysql : 2.9007 Perl : 5.8.7 MySQL : 4.1.12-Debian_1ubuntu3.1-log DBI : 1.48 (find your local versions with attached script versions.pl) I suspect that Paul's data stored in MySQL are not truely UTF-8. Maybe I miss the point, but it seems Perl, MySQL and UTF-8 are not working so badly altogether. Cheers, -- Pierrick LE GALL INEO media system

2 2

Re: Holidays and News in HEAD
by Paul POULAIN 13 Apr '06

13 Apr '06

Owen Leonard a écrit : > Hi Paul, Hello Owen, > I have a couple of questions about Holidays and News. Let me know if I > should direct them at Tumer instead. > I'm trying out the news script and it seems to work great. I'm not sure > about the 'lang' selection list when adding news: > > Librarian interface > CVS > de > en > es > fr > images > it > itemtypeimg > pl > zh-TW > > Obviously this list shouldn't include CVS, images, or itemtypeimg. Right > But if I > choose 'en' for instance, is that supposed to put news on the OPAC? yes, but I did not port the code to OPAC, as PROG templates for opac did not exist when I did this. You just can see news on librarian interface (which are language-independant) > Joshua said he thought you had gotten the Holidays management working. Did > you have to make changes to the template? When I try it with the prog > templates I can't get past the javascript errors. mmm... strange... it worked for me iirc. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)

1 0

Bug in MARC sync in rel_2_2
by Joshua Ferraro 13 Apr '06

13 Apr '06

Hi Paul et al, We discovered a major bug (blocker IMO) in rel_2_2: when items are edited, the marc_word table's old values are not deleted. This leads to a very strange bug where even though the record for an item is correct, searching for the old values (for shelving location for instance), brings up the record. The problem seems to be in the MARCdelitem routine, which modifies marc_subfield_table but never touches marc_word. Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

1 0

numeric identifier in tables
by Pierrick LE GALL 12 Apr '06

12 Apr '06

Hi koha-devel, I've seen some tables in the database where identifiers were not numeric. This kind of things scares me ;-). Internaly, an application should always manage identifiers numericaly, instead of limited alphabetic identifiers (4 characters, uppercase, A-Z only). Why don't we always use numeric identifiers? I suppose because we want users to have an easy way to remember their record. My previous experience learned me to solve this issue by having an internal identifier (numeric of course) and an external identifier (which is shown on screen, alphabetic with restrictions). Their is also a uniqueness constraint on the external identifier (which I call "code"). For example: bookfundid bookfundcode bookfundname 1234 ABCD My personnal fund 321 WXYZ My brother fund On screens, only the code would be shown, not the id. Personaly, I don't think code (easy to remember identifier) is useful, id + name are enough. Cheers, -- Pierrick LE GALL INEO media system

1 0

Managing item type images
by Owen Leonard 10 Apr '06

10 Apr '06

Hi everyone, Pierrick just committed some work on item type image management in HEAD, and his comment in the CVS log got me thinking: "new: function were added in C4::Koha to manage itemtype image location (local/remote). Warning: you must copy or symlink the itemtypeimg directory from the opac template into the intranet template." Copying or symlinking sounds like too much to have to do during an installation, so I was wondering how better to handle the item type images. Joshua made what I think is a good suggestion, to put the itemtypeimg directory inside the koha-tmpl directory. Then we create a directory for each template: /koha-tmpl/itemtypeimg/css /koha-tmpl/itemtypeimg/npl We talked about using a system preference to specify the file extension, to create item type images like this: <img src="/koha-tmpl/itemtypeimg//TMPL_VAR NAME="itemtype" -->. ...where 'extension' is '.gif,' '.png,' etc. But the current system does a directory listing of everything in itemtypeimg, so that's not necessary. I'm wondering if instead of making the item type images template-dependent (css,npl,whatever) like I suggested above, we should have them be independent, so that libraries could choose an icon set independently of their current template. The management screen on itemtypes.pl could have a drop-down list of item type sets found in /itemtypeimg/. That would give us the freedom in the future to add original sets of item type images that other libraries or developers might create. What does everyone think? Would there be any problems associated with moving itemtypeimge into /koha-tmpl ? -- Owen ---- Nelsonville Public Library http://www.athenscounty.lib.oh.us

2 1

Re: UTF8
by Joshua Ferraro 07 Apr '06

07 Apr '06

(copied to koha-devel) On Fri, Apr 07, 2006 at 07:38:02PM +0300, Tümer Garip wrote: > Hi again, > While waiting for Owens directions for CVS time is passing by and I > think we have to sort a few things out. Regarding this UTF8 I think a > little bit more work should be done. Unfortunately I do not have a Linux > system to test things but they should not be that much different than > windows platform. Is there anyone willing to try my scripts as I direct > him/her probably by email or IRC? Of course, I'd be happy to do this. Let me know of a time to be on IRC and we'll do it. > Up until now the only reason KOHA managed both Unimarc and MARC21 is > because of the existence of char_decode script in biblio.pm and unless > somebody comes up with a ready perl module doing the Unimarc charset > conversion to UTF8 everything will get delayed. In fact, the spanking new CVS version of MARC::File::XML does this nicely (you'll also need the new MARC::Charset and new MARC::Record, not available on CPAN unfortunately). You can install it by first checking out a copy of the CVS: $ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/marcpm co -P marc-record $ cd marc-record $ perl Makefile.pl $ make $ su make install $ cd .. cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/marcpm co -P marc-charset $ cd marc-charset $ perl Makefile.pl $ make $ su make install $ cd .. cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/marcpm co -P marc-xml $ cd marc-xml $ perl Makefile.pl $ make $ su make install $ cd .. (or the equivilent on a windows system) Check the POD documentation for MARC::File::XML for how to handle UNIMARC conversions to UTF-8 (or check a message to koha-zebra from Mike Rylander with MARC::File::XML in the subject) > This script was reading UNIMARC and converting it to iso8859 so why it > cannot convert to UTF8 I do not understand. The only reason I can thing > of is that the script contains s/\xc1\x61/à/gm; for unimarc. If > somebody replaces this 'à' character to its UTF8 hexcode than it should > work. Because biblio.pm itself is iso8859 file this character is read as > iso8859-1. What I did (but not sure whether it will work with Linux) is > to save the biblio.pm as a UTF8 file. This way I did not have to write > the hexcode for the characters so they are actually UTF8 themselves. > > Can somebody try this with bulkmarcimport.pl and see what happens? It > works for me. If it does work than I'll give detailed info about because > MARC8 coming from mysql is a litle bit more tricky. I think moving forward, we want to use MARC::Charset for conversions, adding on to it's functionality rather than using our internal char_decode (which in fact, I've removed from HEAD). What do others think? Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

1 0

addbiblio & cloneTag
by Paul POULAIN 07 Apr '06

07 Apr '06

Hello all, A few days ago I have introduced a cloneTag javascript for cloning tags, like the cloneSubfield is cloning subfields in the MARC editor. It did not work well for authorities entries : the authority reported was based on the hardcoded number of the subfield with the ... I rewrote it and now, it's better : there is a <div id="tagXXX"> for each tag. The report is done on every subfields under the <div id="tagXXX"> A last problem remains : the "tagXXX" is hardcoded in the openAuth entry. So when you duplicate a field, the ... still points to the 1st entry "tagXXX". You can search an authority, but if you report it, it's reported to the 1st tag in the biblio ! (the duplicated tag has a <div id="tagXXtagXX">) I see 2 possibilities to solve this : - rename the link when cloning the tag - calculate the id of the <div id="tagXX"> only when the user clic on the ... But I don't see how to solve this problem. I'm happy with what I learned (thx to joshua for some useful links), but i'm still a dummy at javascript & would be happy if someone could take the ball & fix it definetly. hint : addbiblio.pl, line 188 is where the link (...) is builded, it's not in the template, don't look at it here ;-) PS : I won't release 2.4.0 until this problem is fixed. We also have a problem with MARC21/UNIMARC and unicode/iso8859-1, that kados should look at soon. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)

1 0

XML-UTF8-UNIMARC
by Tümer Garip 07 Apr '06

07 Apr '06

Hi, I have seen commits of retrieving a marc record converting it to xml and back to marc to convert MARC8 to UTF8. Well as far as I know Unimarc is not MARC8 so whether it will work with that I'am not sure. Also what I am surprised is that we already have a char_decode script in biblio.pm which is supposed to do this i.e. Convert from UNIMARC and MARC (separately) to previously iso-8859 and now it should to UTF8. Being on a windows platform this actually works for me but I dont know linux issues. So here is the solution(!) I came up with. The records coming from breeding farm into addbiblio.pl are MARC8 and with every communication set to UTF8 they become gibberish because both are double byte characters and mysql assumes them to be UTF8 while they are not. Of course not a problem with the ascii character world. So when I am reading from the breeding farm I set the communications to latin1 temporaryly and suprisingly enough mysql does not try to do any funny conversion on double byte characters and just passes them through as they are. Going through my char_decode they properly get converted to UTF8. If am not mistaken this should work for UNIMARC as well. I do not know the mechanics behind all this but a hint. Just some food for thought for UTF8 gurus, Cheers Tumer

1 0