uccx script cannot split a double variable

[Hk15]

Hello,

i get a "Double" Variable from a SQL Db that i convert to a string in order to split it.

but it's impossible to split with the point ( split"." ) .

did someone has an idea why is not working with the " . " because it's correctly working with " " and "-" ...etc

[Anthony Holloway · Accepted solution]

Try this:

"32.05".split("\.")

[tannerezell]

You need two backslashes "\\." not one, '\.' isn't a valid escape character.

[Anthony Holloway]

I used double quotes, and therefore do not need to escape the escape character in UCCX.

[tannerezell]

You're totally right, good catch. This is a break from the java spec and appears to be a result of the statement itself stored as a string. This should probably be fixed in the parser.

[Hk15]

Many thanks Anthony , it' working

[tannerezell]

Thats because myString.split(".") (notice the string quotes) uses regex to find the split with; in this case you'd want "\.".

You could simply convert your Double to an Integer and call it a day ( myDouble.intValue() );

HTH

Updated. Corrected from \\. to \. per Anthony Holoways comments. His statement is correct, even if it is incorrect java. 

[Anthony Holloway]

LOL to your edit.

Only, it's not Java.

It's technically a separate language all together, which Cisco dubs: Cisco UCCX Expression Language.

"Although the notation in the Expression Language is identical to Java in many cases, it is different in other cases. Also the Expression Language adds more support for creating literals of complex objects and more operators for these complex objects."

Source: https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_11_0/programming/guide/EditorSeriesVol3.pdf

[tannerezell]

Having seen the parser, the expression language is absolutely based on Java with 'niceties' added in to make dealing with java objects simpler; for example, D[now] is a special literal type that translates simply to new java.util.Date(); not having to reference select class types by their canonical names, etc.

Best as I can tell the parser is based on Java 4 or 5 syntax grammars but is not a complete parser for the language. It's important to note that string literals are lazily parsed which is a real shame and why you cannot do something like String myString = "\"hello world\""; This is also why "305.05".split("\.") works as it is parsed into the pseudo structure:

Call( StringLiteral (305.05), "split", new Object[] { StringLiteral(\.) }) which essentially works out to executing the following code

String s1 = new String(new char[] { 51, 48, 53, 46, 48, 53 }); // bytes that represent the string "305.05"
String s2 = new String(new char[] { 92, 46 }); // bytes that represent the string "\." 
java.lang.reflect.Method m = Class.forName("java.lang.String").getMethod("split", new Class [] { Class.forName("java.lang.String") } ); 

m.invoke(s1, new Object[] { s2 });

Could you argue that special language features outside of the java spec make it its own language? Perhaps, but lipstick on a pig is still a pig...

*shrug*

[Anthony Holloway]

Yeah, I agree. The point I was making is that it's allowed to be different from Java. Saying that the split example is incorrect Java is like saying DOC[] is incorrect Java. While true, the language is not Java, and therefore is allowed to be different.