As I mentioned to Ian earlier today, Dave and I were discussing having the jsTrace window keep pace with whatever the most current line is spit out to it. A few hours later, here it is: jsTrace 1.3. I have some other stuff (read: paying projects) that need my attention, so I am putting jsTrace down for a bit. Dave & I will be posting a few more demos of its use in different situations, but as far as further development goes, I’m gonna be hands-off for a bit to let you all get a chance to participate.
And if you’re in the participatory mood, check out this site I built with Adaptive Path. I will be posting some details about the project and how I accomplished certain design features once Kel’s campaign’s over and life gets a little less hectic.
Comments
Thought you might want this to add to jsTrace:
Will print to jsTrace all known properties about a DOM element:
<code class="js">function jsInspect( obj ){ if( typeof(jsTrace) != 'undefined' ){ var d = new Date(); var id = (obj.id) ? obj.id : 'null'; jsTrace.send( obj + ' = ' + id + ' at ' + d.getHours() + ':' + d.getMinutes() + ':' + d.getSeconds() + '.' + d.getMilliseconds() ); var strArray = new Array(); for( element in obj ){ strArray[strArray.length] = element + " = " + obj[element]; } strArray.sort(); for(var ii = 0; ii < strArray.length; ii++){ jsTrace.send(strArray[ii]); } } }</code>It would be nice if I could trigger the delimit externally… oh and predefine the width, height and colour of the window… could the properties be defined pre-declaration of jsTrace and applied on the way through?
Also, could <code class=“js”>jsTrace.send()</code> take a second optional arg of a bgColor for the message and a third optional arg of color for the message. This would allow me to print severe messages in red with black text, most messages would be default, and a few warnings might be orange background.
[Ed. - formatted the code example to improve legibility]
Oh, and I’m now calling jsTrace via an intermediary function… so I can leave it permanently included and just switch one variable to disable debugging, rather than delete the include.
That intermediary function also HTML escapes for me, so it’s much easier to dump out XML which currently is just being output, and thus not visible thanks the tags:
I may roll up these into your uncompressed file if I get a chance… but thought you might be interested in how I’m changing things anyway.
[Ed. - Added a little space so the code would wrap]
And finally… using jsTrace in the <code class=“html”>head</code> of a frameset breaks because of the assumption that <code class=“html”>body</code> exists.
Wow David, you’ve really been running it through the ringer. Let me take each topic in turn.
<ol>
<li>Inspection Function: I like it, but it does feel like it begins to come a little close to what the DOM Inspector for Mozilla already does (and extremely well I might add). A few months ago, I could have seen the point of adding it in for the simple fact that it would be nice to have in IE, but now IE has a (not nearly as useful) Web Developer Toolbar of its own. I am not against adding this feature, but I would like to see a strong argument for it.</li>
<li>Additional hooks: We will be posting a few more functions you can use to tap into things like delimit & clear soon.</li>
<li>Coloring: That’s not a bad idea, let me ruminate on it for a bit.</li>
<li>Debugging Mode Switch: That is the direction I was going to go next with it… I was hoping someone else would build so it would take the pressure off me ;-) I think the best way to approach it is perhaps to be able to pass an argument in the URI string to turn on debugging and have jsTrace look for it in the GET to know if it should open itself or not.</li>
<li>Tag Output: Nice. I hadn’t thought of that & I’d love for you to roll it in.</li>
<li>jsTrace & Frames: It’s been so long since I’ve worked with frames that I often forget about them, but what is your reasoning for including the script in a frameset as opposed to the actual pages pulled into it?</li>
</ol>