What's the rationale behind padding barcodes to a fixed width? I'm not saying I'm against it, I just don't see the point.
Luuk ran into cases with manually entered barcodes (his library - and mine - normal situation) where a value like '000123' may not always have the correct number of leading zeros entered. Also he wants to accept an entry like '123' as finding the above item. He shows some interesting cases in the bitbucket issues for this matter.
Well, first of all I must in a way apology for my bug reporting.
As college becomes busier and my time I can spend on the project becomes less and less I tend to just throw a comment in as a bug when I see something strange without investigation (with an example). Fred is very good in then figuring out what I mean.
(in the coming months until June I will probably have to limit my involvement to using the system and commenting on issues during use as we are hopefully starting to slowly use the system in the next few weeks on multiple sites (in one OpenBiblio) around Ireland.)
In this case I noticed that 13 would not find a barcode 00013, so I fired a bug away. I thought the problem could be solved using a LIKE in the SQL statement, or a wild-card (%) before it. However, Fred had a look at and decided (for now) to add the missing digits. The reason to do this (as I understand, but for some reason email between Fred and myself has broken down in the last few days) is that would only work when there are only digits used in the barcode. But some libraries might use letters as well (eg to denote the location). So maybe we should have a discussion about this, and the flexibility of barcodes.
It seems to me that I ran into this problem with another library several years back. The solution I used at the time was to pass input barcodes to Copies::normalizeBarcode(). Looking at the code, I can see that normalizeBarcode strips leading zeros from the barcode after skipping any letters. It's used automatically by Copies->getByBarcode() if the non-normalized version doesn't get results. I'm guessing the real bug you ran into is that the new code doesn't use Copies->getByBarcode().
I was a bit confused above, normalizeBarcode() does exactly the opposite of what you want. But that is where any kind of normalization should be done.
I'm just starting to follow the new code, and it may use Copies->getByBarcode(), I haven't gotten there yet.
As stated else where, very few Copies functions are being used. This is not one of them.
I would guess that a comment in the code as to the purpose of the normalize function would be helpful as I often wondered what it was for. I think that really should be done anywhere a regular expression is used as I trully beleive that stuff falls well with in the concept of 'write-only code'.
This is probably good advice. I've added a comment. I grew up on Unix and Plan 9, where regular expressions are almost a native tongue, but I shouldn't assume that's normal.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.