This error could be more useful

Error sourcePage Name:/Ticket.xsp

Exception

com.sun.faces.el.impl.parser.ParseException: Encountered “(” at line 1, column 28. Was expecting one of: “}” … “.” … “>” … “gt” … “<” … “lt” … “==” … “eq” … “<=” … “le” … “>=” … “ge” … “!=” … “ne” … “[” … “+” … “-” … “" … “/” … “div” … “%” … “mod” … “and” … “&&” … “or” … “||” … “?” …
Encountered “(” at line 1, column 28. Was expecting one of: “}” … “.” … “>” … “gt” … “<” … “lt” … “==” … “eq” … “<=” … “le” … “>=” … “ge” … “!=” … “ne” … “[” … “+” … “-” … "
” … “/” … “div” … “%” … “mod” … “and” … “&&” … “or” … “||” … “?” …

  • It is good that it indicates the error is an open parenthesis, at least. However:
  1. Line 1 column 28 has no bearing on the code on the XPage itself, that I can see, either in the Source tab or the “Script Editor”.

  2. The error line is actually in a nested custom control on Ticket.xsp, not that page. Since this custom control is nested three levels, indicating the xsp is not useful information. Had I not just changed JS on that cc it would be pretty much impossible to tell where the error really occurred. Please don’t repeat the “debug Formula in fields” nightmare with XPages.

  3. The “Script Editor” finds nothing wrong with this code. I would expect it to complain about what appears to be a syntax error at run time.

  4. The first line of the script block that’s causing this error has no parenthesis in it. How can it encounter what doesn’t exist?? So I guess it’s not so useful that it says the error is a open parenthesis, because there isn’t one.

  5. The real error is two-fold:

  • First the “Script Editor” automagically put in a CDATA tag, which the faces parser is apparently unable to process, and which must enclose everything in a parenthesis behind the scenes, because the first parenthesis in my code is on the second line, and “if(booleanVar) {” is a valid line in JavaScript. If I take that CDATA out, it runs. That means no &&, no ", nothing that the XML editor considers special, anywhere in my script block, because CDATA must be used to include those, and that breaks everything.

  • Second, the faces parser appears to be utterly ignoring comment indications, so // in front of a line is still parsed for proper syntax at run-time, even though it should rightly be ignored.

  • Does Lotus know about these things? I’ll happily copy and paste this post into a service request so someone can tell me it’s a known issue, or someone from Lotus can indicate that here prior to me cluttering up the PMR database.

Thanks for your time…

Subject: To insure inconsistency, manually using CDATA works - sort of…

  • Not only that, but now that it has worked once, after manually pasting a <![CDATA[ in the Source tab, if I delete all code and let the “Script Editor” put the xp:this.value<![CDATA[ back in “for” me, it works.

  • Nice. DDE strikes again.

  • The faces parser, however, is still erroneously parsing comments as valid script. PMR time, I guess.

Subject: I’d open the PMR anyway…

The XPages team is ultra-serious about stuff like this (though it sounds like part of the problem here is the DDE team) so they’d like to know about it at least.

If you do report it and it’s already known/addressed then L1 support should at least give you that info within 24 hours or so.