One of the most difficult parts of converting JavaScript from CRM 4.0 to 2011 is handling situations where the developer did not use a terminating semicolon. Actually, this is a problem with JavaScript in general, as I was reminded this week when I listened to the Drama episode of the This Developer’s Life podcast. That got me to thinking that maybe I should mention it here to add the the JavaScript Conversion knowledgebase.
The Situation
JavaScript doesn’t actually require you to insert a terminating semicolon. If you do not, the JavaScript runtime of the browser will insert one for you.
The Problem (in general)
Problems arise when the JavaScript runtime “guesses” incorrectly, inserts a semicolon where one is not supposed to be, and it alters the execution of your JavaScript.
The Cause
Sometimes this occurs due to an oversight on the part of the developer ( just plain didn’t type it in ). Other times it is because the developer did not know any better. A lot of CRM users who are new to JavaScript simply type in code and don’t understand the underlying reasoning behind it. Finally, some JavaScript developers think a semicolon detracts from the code readability and don’t use semicolons for that reason.
Regardless, it can lead to problems.
The Problem (specific to the JavaScript conversion process)
The CRM JavaScript Conversion Assistant actually performs a Lexical Analysis of the JavaScript being converted.
During this “tokenization” process, semicolons are not actually inserted, but the locations where they should be are treated as if a semicolon existed so the tokens are properly generated. This, for the most part, works as you might expect, and in much the same way that a JavaScript runtime would.
Issues start to arise during the actual conversion process. As I mentioned, semicolons are not actually inserted into the token stream. This means that if the token conversion process is looking for a terminating semicolon, errors can be generated when one is not found.
In most cases we have constructed the token conversion process to take this situation into account, but there are probably edge cases where the code is written in such a way as to cause a conversion failure.
If you run into this situation, then please send us the code segment that is causing the issue and we’ll work to create a fix.
Conclusion
In general, when performing the conversion from CRM 4.0 to CRM 2011, it’s a perfect time to fix any code-design issues you might find. So, keep an eye out for the missing semicolons and add them where required.
Further Information:
7.9.1 Rules of Automatic Semicolon Insertion
http://cjihrig.com/blog/the-dangers-of-javascripts-automatic-semicolon-insertion/
http://elegantcode.com/2011/01/12/basic-javascript-part-6-automatic-semicolon-insertion/
