Introducing frontend developer toolbar

Hi everybody,

This post is dedicated to a small script that I wrote in my free time. The script organizes and presents in a nice way various debug information that you can output on your Dynamicweb pages.

Update: The source code of the frontend developer toolbar is now hosted in GitHub.

Displaying debug information

For those of you who doesn’t know, you can “tell” the system to display various debug information when the page is loaded. For example, you can see a database statistics, trace information, get a list of all available template tags for a given template and also get some insight on system state. Let’s see how to output this information.

To get a database statistics you need to add “dbstat=true” to your page URL (e.g. “http://www.somedomain.com/Default.aspx?dbstat=true”). This will output a list of all queries made to database/search index during the page load process. The list is presented on top of the page above all the content.

If you want to see trace information (as well as some of the details about page state), you need to add another query-string parameter – “debug=true”. The details are displayed at the bottom of the page.

To get a list of all available template tags you need to insert a “DwTemplateTags” tag into target template. The output is also displayed at the bottom of the page.

The problem

The problem with the above approach is that the information that you get is kinda hard to consume. It’s presented differently in a different places. Sometimes it’s extremely hard to read it because it has minimum formatting applied so for example if you have a dark background on your page, you will have to select the entire page contents (by pressing CTRL+A) in order to highlight the text so it becomes readable. Another inconvenience is that the debug output usually breaks the layout of the page (as well as client scripts) making it harder to interact  with the page while debugging.

The solution

In order to solve the above problems I wrote a small script (called Debug.js) which parses all debug information and presents it in a nice way by rendering a toolbar at the bottom of the page which looks a bit similar to Firebug or Chrome Developer Toolbar.

In order to use the script you only need a jquery to be available on a target website. The key advantages of using the script are the following:

1. It collects various debug information and presents it in a nice way.
2. It doesn’t break the layout of the page.
3. No need to upgrade your Dynamicweb solution.
4. The script was tested on the following Dynamicweb versions: 7.2, 8.0, 8.1 (in theory it will work on even 18.x versions).

You can get the script by downloading the minified version (~35 kb) of it from our Developer Portal: http://developer.dynamicweb-cms.com/Files/Filer/Downloads/CustomModules/Debug.min.js. The newest version is on GitHub.

If you don’t want to upload the script to your website (or maybe you simply have no access to the target website), you can use it via the following bookmark: javascript:jQuery.getScript(‘http://developer.dynamicweb-cms.com/Files/Filer/Downloads/CustomModules/Debug.min.js’)

This is how the toolbar looks (for the purpose of the demonstration I’ve enabled all debug information to be outputted meaning that I have “debug=true&dbstat=true” in the query-string as well as “DwTemplateTags” in master template):

The toolbar consists of several tabs as well as the status bar which shows you the brief information about the page execution: how long did it take to load the page, what stylesheet and page Id is it and what template was used as a master template.

Let’s talk about each tab now.

Tab “Performance”

This tab (which you can see on the above screenshot) displays trace information. On a left you have an event time, the main area is occupied by the event data and on the right you have two numbers that represent a time elapsed since last event (green) as well as time elapsed since the beginning of the execution (red). The “Raw view” button allows you to view the raw event data (we will talk about this feature in a moment).

Tab “Cache”

This tab contains information about the page state (as well as application state):

As you can see on a screenshot there are several sets of values that are available. Each item in each set is represented by key, value and value type. The last set is simply called “Set #1″ because the parser doesn’t really know what it is so it cannot name it (the total number of available sets may vary from solution to solution).

Neither “Performance” nor “Cache” tabs are visible if you don’t have a “debug=true” in the query-string.

Tab “Database”

Probably one of the most interesting tab. This tab contains information about all SQL/search index queries made during page load process:

This tab is not visible if you don’t have “dbstat=true” included into the query-string.

Tab “Template tags”

On this tab you can find information about all template tags defined in the target template (in case you have “DwTemplateTags” defined somewhere. Otherwise this tab will not be visible):

Again, it’s not really possible to name the sets so you just see the auto-generated headings. But usually the last set contains global template tags.

Raw view

As I said earlier, “raw view” allows you to view the raw data about the particular record. Here’s an example of “Raw view” that displays details about the single SQL query (the query itself as well as the call stack):

Known issues

The toolbar renders incorrectly in Internet Explorer if you have “dbstat=true” in query-string.

Status of this project

First of all, this is not the official functionality. As I mentioned at the beginning of this post, it was made “just for fun”. The reason why we don’t want to make it standard is that we want to first perform some substantial work on the quality of information that is outputted when you use any of the mentioned “triggers”. But probably the official version will look more or less the same as this one. And probably it will become available pretty soon. In a meantime, you’re free to use this script.

Conclusion

I hope you liked what you saw. If you have any questions regarding this functionality, would like to report a bug of propose a feature – feel free to comment on this post.

Take care.

About these ads