Two Different Worlds

As soon as I announced Formaldehyde somebody asked me:

... and what about FirePHP ?

Formaldehyde is completely different from FirePHP, let me explain why.

Different Purpose

While FirePHP lets developers decide what to debug in FireBUG and what not, allowing a basic system to catch errors or exception, Formaldehyde does not require any change in any part of the application, except, where necessary, this single piece of code: require_once 'formaldehyde.php'; Moreover, Formaldehyde should catch every kind of error, included the most problematic one, the Fatal Error, which will probably let FirePHP silently fail.

FirePHP.class.php ```

line 343

//NOTE: The following errors will not be caught by this error handler:
//      E_ERROR, E_PARSE, E_CORE_ERROR,
//      E_CORE_WARNING, E_COMPILE_ERROR,
//      E_COMPILE_WARNING, E_STRICT

``` As summary, Formaldehyde is better suitable for all those not managed errors rather than for client side log report, which could be useful if we would like to know also what is going on during the execution.

Different Targets

While FirePHP is both server core library and a Firefox Plugin, Formaldehyde is client side agnostic. OK, OK ... I guess 90% of web developers use Firefox and Firebug, but thanks to its agnostic nature, Formaldehyde could be implemented in two lines in every kind of client side library and for every kind of browser. ```

xhr.onreadystatechange = function(){ if(xhr.readyState === 4){ if(199 < xhr.status && xhr.status < 400){ ... OK stuff ... }

    // add Formaldehyde Support
    else if(xhr.status === 500 && xhr.getResponseHeader("X-Formaldehyde") != null) {
        console.log(JSON.parse(xhr.responseText));
    }

    else {
        ... Error management ... 
    }
}

};

```

Unobtrusive Approach

One of the main goals of Formaldehyde is to avoid to change our code style thanks to its Zero Config nature. We do not have to care at all about the API, the way it works, future changes, and most important we do not have to change anything the day we'll decide that Formaldehyde is not useful anymore because we have implemented 100% of errors and exception management by our own. Well, what I can say is that a manual and correct implementation of errors management is always a must, but again, Formaldehyde would like to take care about unexpected problems, rather than problems we know or we can fix. From this point of view, FirePHP can probably be a better support, but at the same time is less flexible because it requires specific calls inside our code, so it is a bit harder to get rid of it, the day we'll implement a dedicated error and debug manager.

Zero Config, Zero Code, Zero Performances Problems

With FirePHP we need to comment out, remove, set flags, whatever, to avoid its initialization or to avoid its execution. But even if the final output or the debugged code will not be managed, or sent, each instance call, each instance method call, and every part of FirePHP dedicated code will be executed, which simply means a little, but necessary, performances slowdown. It is not a problem strictly related to FirePHP, it is, generally speaking, what's up with any kind of log and error manager. Formaldehyde won't slow down our applications, except for a couple of function definitions, removable, if necessary, commenting out the require_once directive, that's it.

Formaldehyde AND FirePHP

Since Formaldehyde acts basically only when an error occur, a FirePHP application riches of manual log, warn, or other calls, should work without problems, specially because FirePHP is mainly based on headers, and there are no compatibility problems between Formaldehyde headers and those generated via FirePHP. So, as summary, it should be possible to combine together but I have already contacted Christoph Dorn about a possible Formaldehyde plus FirePHP distribution via FirePHP itself, so stay tuned ;)

Update - The formaldehyde_log Exception

After I wrote this page and patched formaldehyde to version 1.03 for a couple of typos and few fixed bugs, I have realized that a simple log system could be useful in any case. Being formaldehyde_log 3 lines of function I can say it cannot replace any other log oriented application but at least now there is a dedicated header, X-Formaldehyde-Log, which contains key/value pairs stored via JSON and assigned in this way: formaldehyde_log('my key', $mygeneric_variable); Both X-Formaldehyde and X-Formaldehyde-Log are now always present, whatever the page will finish successfully or not, so we can monitor, if necessary, both logs, elapsed time, plus status 500. The reason I have implemented this new header is simple: during one test I could not understand what was going on, and a header is something properly managed without problems whenever we set an output buffer. My suggestion is to do not use formaldehyde_log directly in code, but to wrap this function inside whatever other log manager is present or create a dedicated callback. Please Note that in any case this function could be used with formaldehyde enabled or disabled, and the internal $log store is always returned.

Update - The Formaldehyde JavaScript File

I am proud to announce the client agnostic, cross-brower, zero dependencies, and zero configuration, formaldehyde.js file, now featured in home page. All about Formaldehyde is respected in the client file, we do not have to change a single line of our code. All we need to do is to include in development environments formaldehyde.js as first script, before libraries, before our code, and simply remove it in production. It is that simple, and it is still browser and code agnostic.

Enjoy