Debug Environment for DT/Editor/PHP

JW

Howdy,

I'm curious, what is the most effective way to debug a DataTable, Editor and PHP application? A bunch of console.log() statements with PHP print statements? Is there a specific IDE and client install of Apache (XAMPP?) combo that works well? Maybe some remote debugging build and IDE? Or do people have some other setup that works well in tracking not only the JS code on the frontend but also as the data transfers back and forth with the PHP libraries on the backend?

Thanks in advance for any help!
J W

allan

The tools I use will depend upon what exactly I need to debug. Editor's PHP libraries have a ->debug(true) method that can be used to show the SQL that it is executing which can be useful, and you can also call ->debug() with a string and have that passed to the client-side when the server sends a response. The later can be particularly useful if debugging events, or something inside the PHP library code.

For client / server data interchange, the browser's Network inspector is always by go to, and on the client-side the browser's script debugger is exceptionally useful.

There isn't a single best tool that will do everything (that I'm aware of), but rather a combination of tools.

Allan

JW

Great! Thanks for the thorough and quick response. I should have read more about ->debug(). I didn't realize it could actually pass strings back to the client. I've used ->debug(true) to look into the actual PHP query being run/debug it. It's been very helpful.

OK. So I was on the right path in terms of using the dev tools in FF. It looks like I will just need to become more proficient with them; especially the Browser debugger and console. I really want to be able to look into certain properties or variables at a certain point in the applications execution (like watches) but JavaScript isn't as linear as other languages. In other languages, the variable/objects/properties are "available" for you to watch as soon as the line of code has been executed and for the entirety of the programs execution. In JS, variables/objects/properties can go in and out of visibility to the client based on what's happening within the document (events, button pushes..etc). So most of the time, I can't figure out how or where to place the breakpoint/watch that will give me that information or use the console to look into those same values. Seems like, no matter where I look for that data, it always comes back undefined and null.

Again, thanks for your help. I'll look for some tutorials on client-side JS debugging to get a better feel.

J

allan

I didn't realize it could actually pass strings back to the client.

That's a new feature. I need to write up a "how to debug Editor" document at some point with that kind of thing in it!

The way I often use the debugger in the browser is to search for the code I know I want, then put a break point on it. When the browser hits that line it will stop executing so you can inspect the values of it and other properties in that context. Very useful!

Allan

JW

to search for the code I know I want, then put a break point on it.

Thanks Allan. My issue most likely goes back to my lack of knowledge in how JavaScript executes and how scope is so dynamic with things coming on and off the stack. Sometimes I will put a breakpoint in a location I want to look at but for whatever reason, the breakpoint never fires and I'm back to square one.

Starting to wonder if the way our files are structured has something to do with it. For various reason I won't go into and I'm sure could be debated, my front-end files, which include all the DT code as well, are normally *.php files and they contain PHP, JS and HTML in the same file. I wonder if that's why I run into problems and the debugger doesn't quite know what to do. However, the more I think about that..I'm not sure that holds much merit. Anyway, don't worry about it too much. I'll figure it out. Thanks again for your previous responses.

JW

I know that in my reply immediately above I just basically said close out this post, but maybe it would help if I provided an actual example. Here's an example of a breakpoint within a snippet of code for your Duplicate button example that doesn't fire when I expect it to. The breakpoint I put is on the 'action' property and it's associated function because I want to step through that function and see how it works:

buttons: [
...
{
    extend: "selected",
    formMessage: function ( e, dt ) {
        return 'Are you sure you want to delete the entries for the '+
        'following record(s)?';
    },
    text: 'Duplicate',
    action: function ( e, dt, node, config ) {
        editor
            .edit( table.rows( {selected: true} ).indexes(), {
                title: 'Duplicate record',
                buttons: 'Create from existing'
            } )
            .set('prevOrderId', table.row( {selected: true} ).id().substring(4))
            .mode( 'create' );          
}],
...

My expectation would be that the debugger would pause and break when I clicked the Duplicate button. However, when I refresh the page in FF, it breaks on the initial load before the DT is even created. If I step through, the DT loads and everything is fine. When I hit the duplicate button though, the debugger never breaks at the breakpoint again. I know I'm greatly misunderstanding something...I'm just not sure what that is.

J

allan

Put the breakpoint on line 11 in the above code - i.e. inside the function that the action will execute. Don't place it on line 10, that code is executed when the button is initialised.

Allan

JW

Yup. That did it. Ugh! Shows you how long it's been since I debugged. That same behavior happens in every language as I recall...now. Deleting my account. Thx, Allan. You can close this thread now.