JavaScript Debugging Hints
Even though the Script Editor makes scripting fast and convenient, the JavaScript language poses its own special challenges. One of the biggest challenges is debugging. Unlike strongly typed languages, JavaScript does not have fixed type for variables, which means that no compile type error checking can be done.
This chapter offers a few tips and hints on how to deal with debugging in JavaScript.
 |
Click this screenshot to view a three-minute demo and get an overview of what InetSoft’s BI dashboard reporting software, Style Intelligence, can do and how easy it is to use. |
1. Keep the Script Small
The smaller the code, the easier it is to debug if anything goes wrong. Since scripts are normally used to perform relatively simple calculations, there is little reason to introduce complicated structures or organizations. Use functions and the Script Library to help keep your code concise. (See Script Library.)
2. Associate Script with Elements
Since a script can access any element in a report, in many cases it is possible to write a single large script to perform all tasks. This poses a few problems, however:
• A large script tends to grow and become more complicated over time. This makes debugging the script much more difficult.
• If a single script affects many elements, whenever you rename or delete one of those elements, the script will generate an “object not defined” error. This kind of dependency makes report maintenance difficult, because it is not clear to developers which report elements might be under the influence of a remote script.
• When a script on one element affects the properties of other element, the efficacy of the script depends on the order in which the elements are evaluated. Because the rules for element evaluation (see Script Evaluation) are varied, it can be difficult to predict the final result of the script.
To avoid all of these problems, the script that you place on an element should affect only the properties of that element. For example, if you need a script that modifies the properties of element Text1, then add this script to element Text1. The majority of scripts are element-specific and should therefore each be attached to their associated element.
However, certain scripts need to access multiple elements in order to perform calculations, and it would be difficult to break these up into smaller pieces. In general, if a script works on multiple elements, it should be placed in the onLoad Handler. This eliminates the ambiguity of evaluation order: Since the onLoad handler is called before any element-script is evaluated, all onLoad actions take effect in the current thread.
3. Use log() to Output Diagnostic Messages
Log() is a global function that can be called to send a message to the log. In Report Designer, log messages are displayed in the Console window. On the report server, log messages are added to the sree.log file and printed to stderr. Log messages can be used to verify whether a script is invoked or to check the order of script execution.
log("Text changed to: " + text);
4. Protect Reports from Script Errors
Because scripts are executed when the report is generated on the server, a script error can cause report generation to fail. To prevent this from happening, you should wrap failure-prone code inside a “try-catch” block, which allows you to trap errors before they affect report execution. See Appendix JS.10.4, The 'try-catch' Statement, for more information.