Incorrect value of target for Autocomplete object

[divby1]

Okay, so after being put into production some anomalies popped up in
our use of the AutoComplete and Data objects.

For most users the control works fine. It reads the source field and
fills in the target field with the employees id that it receives from
the parser. With some users however it fills the target field with a
number that is not their employee id and exists nowhere in the data
for that user.

I was using a custom parse function I wrote and thought this might be
the problem so I changed to use the CFQueryToJSKeyValueParser and the
same behavior can be observed.

My Autocomplete Object is as follows:
new mxAjax.Autocomplete({
indicator: "indicator",
minimumCharacters: "2",
target: "uupic",
className: "autocomplete",
paramArgs: new mxAjax.Param(url,{cffunction:"hotLook"}),
parser: new mxAjax.ldapQueryToJSKeyValueParser(),
source: "name",
postFunction: autoFill
});

The Parse function is as follows:
// Added on 08/06/08 by Kevin Thomson (custom parser to handle ldap
queries)
mxAjax.ldapQueryToJSKeyValueParser = Class.create();
mxAjax.ldapQueryToJSKeyValueParser.prototype = {
initialize: function(options) {
options = (options != undefined) ? options : {};
this.type = "ldapQueryToJSKeyValueParser";
this.setOptions(options);
},

setOptions: function(options) {
this.options = Object.extend({
delimeter: options.delimeter ? options.delimeter : ",",
callno: options.callno ? options.callno : 0,
path: options.path ? options.path : ''
}, options || {});
},

parse: function(content) {
var myObject = JSON.parse(content);
data = ([content].grep(/"calls"/) == "") ? myObject : myObject.calls
[this.options.callno].data;
if (this.options.path != "") data = eval("data" +
this.options.path);
//Object.dpDump(myObject);
var fields = myObject.COLUMNLIST.split(",");
this.itemList = Array();
for (var ctr=0; ctr < myObject.RECORDCOUNT; ctr++)
{
// Edit on 08/01/08 by Kevin Thomson (display full name in source
field and dropdown)
this.itemList.push({key:myObject.DATA[fields[0]][ctr],
value:myObject.DATA[fields[3]][ctr]+", "+myObject.DATA[fields[1]][ctr]
+" "+myObject.DATA[fields[2]][ctr]});
}
return myObject;
}
};

When I started looking at what was going on in firebug I noticed that
the responseText from mxData always contains the correct employee id
but when you get to the "parse: function(content)" part the content
object contains the data segment with an incorrect employee id that is
only 7 digits. The same content object contains the responseText with
the correct 9 digit employee id however.

I'm at a loss for where this 7 digit number is coming from that is not
the employee id and exists nowhere else in the record.

Furthermore I'm at a loss for why this only occurs for some users
while others have the correct employee id in the data segment of
content. There is not a consistent difference between users this works
for and users that it doesn't. There are some records that have
multiple leading 0s that I'm checking for in javascript before I
perform my second lookup with their id to fill in the rest of the
form. Other records with leading zeros display just fine, and there
are records that have this problem that do not have leading zeros.

[divby1]

Upon further troubleshooting it was found that JSON can't handle
numbers with leading zeros officially, this slipped by at first
because it does actually work with most occurrences with a leading 0
but there are certain patterns that do cause problems. For example a
leading 010 causes the bizarre conversion to the 7 digit number from a
9 digit number

I appended a character onto the front of the number so that it will be
treated as a string before I'm sending it back as a cfquery and this
fixed the problem.

Additionally I moved my formatting of the name into my CFC using a
query of queries to construct the autocomplete value with the employee
number as the key. This allowed me to go back to using
CFQueryToJSKeyValueParser instead of the ldapQueryToJSKeyValueParser
used previously.

[Lance]

In almost every instance I can think of a number never starts with a
zero. Only a numeric text string could start with a zero.

[divby1]

Employee ID numbers commonly start with leading zeros.

And since you said numbers and not integers 0.6 starts with a zero.

Now if you had said that you can't think of an integer data type that
supports a leading zero I would agree with you.

mySQL of course has the zerofill option that you can add to an integer
field to pad the left hand side with zeros.

But back to the point, integers most definitely can have leading zeros
unless your telling me that 01 is not an integer.

So lets prove that, first lets just assume 01 is an integer and lets
try to use it in some properties of integers.

01+2 = 3 and 01*2 = 2. Since 2 and 3 are integers 01 passes the
closure test.
(01+2)+3 = 01+(2+3) and (01*2) * 3 = 01 * (2*3). Associativity
property check.
01+2 = 2+01 and 01*2=2*01. commutativity property check.
01+0=01 and 01*1=01. identity property check.
01+(-01)=0. inverse property check.
01*(2+3)=(01x2)+(01*3). distributive property check.

Quod erat demonstrandum, thus is is proven that 01 is an integer.

I think you are either confused about significant digits or you simply
meant that most integer data types drop insignificant digits in order
to save space. It doesn't mean they don't exists. It just means that
the designers of those data structures made a choice to to save space
by leaving out what they didn't need to store.

And as a final disclaimer to you Lance. I'm in no way trying to be
aggressive towards your statement, just having a bit of fun. The
important thing is that someone else that had the problem I noted in
my first post might be helped out by my second post on the 19th. We
should be using this space to help each other out with mxAjax and not
bicker about mathematics.

[Lance]

My apologizes, I never ment that a logical assumption that 01 was not
eqivilent to 1 only that most languages consider '01' a text string
and in order for it to be a number it would have to be parsed which
would result in it being simply one. The original question had to do
with a text string starting with leading zeros being handled
improperly and I was trying to point out that in almost all cases (at
least that I have experienced) a number that starts with a leading
zero will be a text string and not a number. Obviously I did not do a
good job explaining that I for that I am sorry.

I should have stated that the technologies that are discussed in this
group: javascript, coldFusion and most importantly SQL or Oracle will
not (with default database installations) recognize 00001 as being
numeric until that value is parsed. I would bet money on any data
field that contains an EmployeeID that has a leading zero is NOT a
numeric field.

Sorry for the confusion I was trying to help but did a very poor job
of it.

> > zero.  Only a numeric text string could start with a zero.- Hide quoted text -
>
> - Show quoted text -