e.laborate uses a javascript based rich text editor called TinyMCE. We also use a suite of desktop like controls built on top of the Yahoo! UI library called Ext. Like anything else these tools have their benefits and faults. When integrating different libraries such as this, there can often be conflicts. Most libraries end up reproducing similar functionality. This happens because library writers want their tool to be as self sufficient as possible while not adding dependencies. The result is you see each library having DOM manipulation function, Ajax, and a host of other basic features.

Javascript is a very dynamic language in that it uses functions as first class citizens. The impact of this is that I can take any object (such as a string) and add my own functions to its instance. Objects in Javascript end up being simple hashes that contain pointers to functions and attributes. The problem happens when you have libraries such as prototype altering basic types that other libraries use. Namespacing has largely negated this issue, but there are still plenty of areas where things get sticky.

Specifically when trying to load TiinyMCE within an Ext.TabPanel, there came up a question of precedence. The order of loading is very important because the browser loads scripts asynchronously, making the DOM one script possibly different from the DOM another script sees. The tactic to get around this is to essentially chain the events such that when one script finishes, you use its callback events to trigger the beginning of the next script. This can still be a challenge when using things like timers, but for the general case it is an effective means of integrating scripts correctly.

In fact this is exactly what I did to get TinyMCE within an Ext.TabPanel. I let the tabs load an used their activation event trigger adding TinyMCE. The activation event was one of the later events, meaning there are a host of other potentially usable events that were fired before the one I used. With that in mind, by using a later event, any extra DOM elements added to the page by the tabs would already be loaded by the time TinyMCE tried to add its elements to the page.

This analysis of the page DOM was critical and helpful in that seeing the markup each tool added to page made debugging much easier. Firebug was very helpful in this regard because it revealed that my load/reload pattern for TinyMCE was flawed because it added to links to stylesheets for every load/reload. From a conceptual standpoint, looking at the mark up helped to understand what the tool was really doing as compared to what I thought it did. I had an idea of what I wanted to do and thinking in terms of markup instead of visual appearance in the browser helped reduce the boundary between the presentation and code. This also helped to realize potential problems with my approach I never would have noticed. 

Firebug was the most essential tool with Safari's inspector a close second. They allowed watching DOM change after events and evaluating the results. This was incredibly helpful because I got to see how different styles and elements were interacting to mess up the markup. Thinking in these terms really did change the problem and made a solution much easier.