I was looking at how the xul client handled the barcode import, and it handled it using a single split statement.
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/xul/staff_client/server/circ/copy_status.js;hb=HEAD#l470
var barcodes = content.split(/[,\s]+/);
\s matches: A space character A tab character A carriage return character A new line character A vertical tab character A form feed character
so any combination of whitespace and commas would work in the xul client. 29393999393, 2992929299299, 29939393939,,,, 3939399939
Maybe we should just go back to that? Would there ever be a need to allow spaces in the middle of barcodes?
I think the current webclient code could handle something like 1234 567 2344 8888 888 8888
But if we just want to go back to the XUL client behavior then using the same split regex should work.
Otherwise, the webclient code could strip leading spaces also. Josh
I was looking at how the xul client handled the barcode import, and it handled it using a single split statement.
https:/ /git.evergreen- ils.org/ ?p=Evergreen. git;a=blob; f=Open- ILS/xul/ staff_client/ server/ circ/copy_ status. js;hb=HEAD# l470
var barcodes = content. split(/ [,\s]+/ );
\s matches:
A space character
A tab character
A carriage return character
A new line character
A vertical tab character
A form feed character
so any combination of whitespace and commas would work in the xul client.
29393999393, 2992929299299, 29939393939,,,, 3939399939
Maybe we should just go back to that? Would there ever be a need to allow spaces in the middle of barcodes?
I think the current webclient code could handle something like
1234 567 2344
8888 888 8888
But if we just want to go back to the XUL client behavior then using the same split regex should work.
Otherwise, the webclient code could strip leading spaces also.
Josh