revServer Techniques
Learn about de-bugging your server scripts using Firebug, plus a bonus app to view World Cup photos from a live RSS feed.

by Andre Garzia

Introduction
RevServer is a wonderful technology. It enables us, Rev Developers, to use our familiar English-like programming language to easily create web applications in the blink of an eye, but what happens when things don’t behave as expected? It turns out that debugging web applications is not as trivial as debugging desktop applications. For those on the marvelous On-Rev service, debugging web apps is as easy as debugging desktop applications because those fortunate souls have access to the On-Rev client with its desktop class visual debugger, but those that just bought and installed RevServer on their Macs and Linuxes, how should they proceed? This article hopes to present some of tools and tricks you can use while debugging RevServer applications without the aid of the visual debugger from On-Rev.

 The errormode property
Our first friend is the errormode global property which specifies how error messages should be handled. This property has three possible values: inline, stderr, quiet. Let us see what happens when we set them.

To use the errormode property on your script, just do something like:

Set the errormode to “inline” 

Now, let us look at an inline example:

click to zoom

You can see on the screenshot below what happens when you try to access that file. RevServer displays the familiar error message on the screen: “row 17, col 1: Handler: can't find handler”. You can simply go to that line 17 and find what the problem is, as shown in the second screenshot below where I’ve hilited in red the line with trouble.

click to zoom

This is all cool and fancy, but while setting the errormode to inline is a blessing during development, you don’t want your users seeing your coding mistakes. So let us use another example and show what happens when you set it to “stderr”.

Stderr means Standard Error Output, in our case, it usually means the Apache Web Server Error Log File. Let me show you first the source code file, then what is shown on the browser when we access it:

click to zoom

Now when we try to access it in the browser, this is what we see:

click to zoom

Notice that it failed silently. Now, let us look into the apache error log file. This file is usually named error_log and it resides at your configured location for log files. On Linux machines this is usually /var/logs. On Mac this is the same location as well. Let us look into the final lines of that file:

click to zoom

Hilited in red are the lines generated by the RevServer engine error messages. This is a good way to let your web application run and still be able to check on the errors in case they happen. We know that the engine error messages are not very human readable but we can always look them up by copying and pasting the error message into http://runrev.info/error.html which is a handy web application created by Mark Schonewille.

The last errormode option, which is quiet, will simply fail silently with no output anywhere, so there’s no point in using screenshots.

So in summary, we saw the different errormodes and how they help us debug our web application. Now as you can deduce, these error messages are triggered by execution or parsing errors only. What if the RevTalk code is right but our logic is wrong? It is often the case where the code runs without a single error message but the application is not working as expected. In the next section we will look into the web developers best friend, FireBug.

FireBug
FireBug is a Firefox extension for debugging web applications. You may say: “Hey I am a Chrome user” or “Hey I am a Safari user” but it doesn’t really matter because I will show you how to use those two browsers as well. I will first show Firefox because it was Firefox and FireBug that started it all.
You can get Firefox here.
You can get FireBug here.
FireBug is the web developers swiss army tool. It enables you to debug and inspect all things related to web applications, from DOM to xmlHttpRequests to javascript execution. FireBug has everything and deserves an article of its own. Right now we’ll just focus on one aspect of FireBug which is the console.

FireBug's console is like Rev's message box, you can output things there while your application is executing. You can send error messages, warnings, information and group them anyway you like. It actually has many more features than I am showing here, this is just a simple article after all! Let us look into Firefox with FireBug installed. You’ll notice the FireBug icon on the lower right corner if it is installed. If it is gray colored, then it is disabled, clicking on it will open the FireBug pane and enable it. Let me show a shot with FireBug opened:

Handy for us all, I’ve implemented a RevServer library include that can talk to FireBug. It is a part of RevSpark but I am also offering it separately so that you can use it alone. You can download the file and examples here. Let me show you an example source code:

click to zoom

We first include the console.inc library include file. Then we call some console commands in the middle of the source code. We call log, warning, info and error. Now, what happens when we access this page with FireBug enabled:

click to zoom

From the shot it is pretty self explanatory how the RevTalk console commands work. Now, you can see that on the right side there are line numbers, those line numbers do not match the source file line numbers, this happens because FireBug is showing you the line numbers from the rendered page and not from the source code. FireBug doesn’t have access to our source file, we talk to it by issuing javascript commands in the rendered page. This is why the line numbers do not match and why the error message shows a javascript snippet.

FireBug was created to debug javascript, so it gives you information about the running rendered page. Let me show you what the source code for our page looks like:

click to zoom

So keep in mind that some of the information there such as line numbers reflect the rendered page and not the source file. Still FireBug is a great tool because you can debug stuff while using your web application without disturbing your rendered page. For example, imagine you have a complex application such as an intranet agenda and you want to debug some arrays. Instead of using “put” to display the arrays in the middle of the page and break your layout, you can send it to the console.

Example:

click to zoom

Notice that we use a line: console “dir”, tContacts. This “dir” command tells console that we want to inspect the array we’re sending in some pretty way. Look at the output:

click to zoom

Now we can output whole complex structures to the console without disturbing our HTML layout. Another nifty feature is “grouping” that enables you to group sets of messages. I will make a final example showing you all the features:

click to zoom

The browser output:

click to zoom

How cool is that? You might be asking what happens if one of your users has FireBug installed and logs into your web application, will he see your debug information? Yes, he will unless you disable it. Console.inc has a “enableConsole” command and a “disableConsole” command that enables or disables the console integration. One trick is to always call disableConsole at the start of your web application and then call enableConsole only if you know it is you that is logged in. For example, you can use a cookie for that, checking on the admin cookie or if you have a fixed IP address, then, you can check $_SERVER[“REMOTE_ADDR”] and enable if it is your IP. There are many ways to figure out how to decide about enabling or disabling the console.

FireBug is an invaluable tool, not only because of its console but due to the hundreds of other features such as DOM inspection and network transfer audit tools. I said at the beginning of the article that I would show Chrome and Safari as well. It turns out that the webkit guys were so amazed about the power of FireBug that they replicated it on the core of their technology so both Chrome and Safari come bundled by default with Developer Tools.

Safari has a “Show Developer Tools” advanced preference that will add a menu item called “Develop”. Under this menu you’ll see “show error console”. Let us look at the same final example under Safari Error Console:

click to zoom

Chrome has the same Develop feature and it looks cool too:

click to zoom

Summary
So we learned how to use the errormode property to trap the engine error messages and how to leverage FireBug or WebKit developer tools to debug our own web applications. The console.inc file is available at http://hg.andregarzia.com/revspark/ or here in this article.

Now to show you a complex example, let us build a simple RSS reader for the FIFA World Cup 2010. Our idea is to pick FIFAs own Recent Photo RSS and display the last 10 pictures in a web page. We'll use some CSS3 stuff there to use custom web fonts and to give round corners to the pictures. Our web fonts are provided by Google Free Web Font Directory. To see the page live, take your browsers to http://wecode.org/fifa.irev. Use Firefox, Chrome or Safari to see the page at its best.

There is some information that we as developers might want to know but are not interesting to the end user. One piece of information is how long did it take to load the remote FIFA RSS file. Another thing that is interesting is the actual amount of items in that file. Even though we're only showing the last 10 pictures, we might want to know how many pictures are there and lastly we want to check the array we built to hold all the pictures.

In the source code, you can see there are a couple of console calls measuring URL loading time and a final console call to display tPhotosA which is our array holding all the pictures. From the shots, you can see how the page looks to the end user and how it displays with the developer console enabled. This is just an example on how useful console logging can be.

Photo with console enabled - click to zoom

Photo as displayed to end user - click to zoom

Download the source code for this example here.

I hope you all enjoy the new RevServer technology and am anxious to see what you’ll all be doing with it!

About the Author Andre Alves Garzia is 30 and lives in Brazil. He is usually coding something network related and created RevOnRockets. When not working, he enjoys SF Books, sailing and making pizza.