To become an effective User Controls developer for Web Interfaces, you will need to know about the debuggers available to you, the typical JavaScript debugging workflow, and code requirements for effective debugging.
When used effectively, JavaScript debuggers will help you find and diagnose possible errors in your JavaScript code.
In this article, we will discuss some techniques for debugging the client side code of a GeneXus Web application, in the context of a User Control execution. We will use the GX Google Visualization web application sample.
First of all it is important to notice that all GX generated Web applications uses the standard javascript routines available in the gxgral.js file. If you do a View source operation in any page generated with GeneXus with a browser, the following line will be detailed:
<script type="text/javascript" src="gxgral.js?30011"></script>
All the user control references will be called by functions available in this javascript. As this file is by default compressed to improve performance, you can rename the gxgral.src.js file (located in the generator folder) to gxgral.js and copy it to the location where you will do the debugging session to ease readability, in particular if you need to go deep to the GX standard functions execution.
Nowadays, all JavaScript debuggers are really polished and easy to use; there are options available for all major web browsers such as:
It is important to familiarize yourself with this tools, some useful resources are:
The inspector should be part of your day-to-day JavaScript development !!
If you want to start debugging a specific user control, you will have to:
- Find the relevant code in the debugger’s code view pane; generally the associated Render User control file (check the User control definition file), for this example the GoogleCharsRender.js.
- Add a breakpoint where you think interesting things may occur; you could check the show javascript method which details the User control render behavior.
- To add a breakpoint go to the Scripts panel in the inspector, select the relevant script (GoogleCharsRender.js file) and code section, and click on the line number where you want to place the breakpoint.
- Refresh the Genexus object and wait for the debugger to pause it's execution and step through the code.
Regarding our
sample, using
Google Chrome use the
Ctrl+Shift+I shortcut to open the
Developer Tools; then select the desired scripts render file, in our case we should select the
GoogleCharsRender.js file and particularly in this case we want to check how the control is loaded; particularly the data items loaded. For this, a breakpoint is added at the end of the "
CreateDataTable" function.
After refreshing the page the breakpoint is hit, and with just a mouse over you can inspect the data local variable.
Depending on the debugger, you will not only be able to hover the mouse over any variable to see its current value, you can check the stack trace, inspect HTML elements, edit CSS styles, check the page DOM and much more features. Some debuggers add a command line to evaluate javascript code or change variables for testing.
You can continue code execution, step into or over the next function call, and navigate up the current stack using the toolbar.
If you have control on the javascript code, you can use the debugger statement inside the script at the point you want the debugger to pause execution:
this.show = function()
{
// my User Control Code
debugger;
}
Note: when using the debugger statement, please remember to remove the debugger lines when moving to production, otherwise the breakpoint could be hit !!
Using the sample application but in this case the
Firebug debugger you will notice that similar features are available; you can check a variable value, go through different tabs, check the stacktrace execution and so on.
This article only explores how to debug a javascript file; JavaScript debuggers have many more useful features worth checking such as:
- Analyze Network Requests to display all the HTTP requests the page.
- Profiling
- and more.
In some cases an error occurs on the gxgral.js standard file and as this file is compacted, it is difficult to figure out what is happening.
For those cases when you need troubleshooting, you can copy the gxgral.src.js file from the generator folder to the runtime environment where your application is running and rename it as gxgral.js.
Then, clean the browser cache and force a page reload and you will start using the plain text version of the javascript file which is much easier to read and troubleshoot any problem with your User Control.
In general, when a javascript error occurs on the plain text gxgral.src.js file (renamed as gxgral.js) you can use any available javascript debugger to get further information.
It can be useful to know exactly how long something has taken to execute, especially when debugging slow loops. You can even set up multiple timers by assigning a label to the method. Take the following snippet as a sample code; you need to use the methods console.time() and console.timeEnd().
console.time('Timer1');
var items = [];
for(var i = 0; i < 100000; i++){
items.push({index: i});
}
console.timeEnd('Timer1');
The expected result is to get something similar to:
Timer1: 22.211669921875ms
Since JavaScript is not a very structured language, it can sometimes be hard to get an overview of what happened and when. This is when console.trace (or just trace in the console) comes handy to be able to debug JavaScript.
var car;
var func1 = function() {
car = new Car();
car.funcX();
}
var Car = function() {
this.brand = "volvo";
this.color = "red";
this.funcX = function() {
this.funcY();
}
this.funcY = function() {
this.funcZ();
}
this.funcZ = function() {
console.trace("trace car")
}
}
func1();
You will get the following from "trace car"
trace car
Car.funcZ @ VM1252:16
Car.funcY @ VM1252:13
Car.funcX @ VM1252:10
func1 @ VM1252:4
(anonymous) @ VM1252:19
In the Chrome console, you can keep an eye on specific functions. Every time the function is called, it will be logged with the values that it was passed in. Suppose the following function.
var func1 = function(x, y, z) {
//do nothing
};
Use monitor to monitor the function you want and execute the desired code:
monitor(func1)
func1(1,2,3);func1(4,5,6)
The following result is expected:
function func1 called with arguments: 1, 2, 3
function func1 called with arguments: 4, 5, 6
Blackboxing gives you a first-class way to denote library (or other abstraction) code so that the debugger can route around it. When you blackbox a source file, the debugger will not jump into that file when stepping through code you're debugging (more information).
Useful Javascript functions available in the gxgral.js