Escaping Console.log()

Firebug icon Ray Camden just Twittered about checking in code that still has console.log() in the Javascript. He rightly points out that console.log() causes problems for browsers that don't understand it, but you don't really have to have Firebug installed as some browsers like Chrome understand it natively. Rather than try to purge my code of console.log(), and need them again later, my solution is to add an "escape" that lets console.log() evaluate harmlessly on browsers that don't support it. Click more to see the code.

 

Wild Friday Night with Javascript Controllers

Javascript code All because of Ben Nadel, I'm writing Javascript examples instead of playing Fallout 3 tonight... Ok, so in my post evolution of a js controller scheme, Ben commented that he wasn't comfortable with the idea that the this value inside my controller was the window object, rather than the controller itself. So, I've set out to see if I can rework the controller to use "new" and grow up to be a real object. Read more to see how I do.

 

Evolution of a JS Controller Scheme

It took me quite a while to discover the power and flexibility of a controller scheme for Javascript, but thanks to some awesome videos and tutorials, I've come up with a setup that works quite well, and I thought I'd share it with you. I'm going to start with a basic object, and evolve it into what I use, so you can understand why each thing is done, and what happens at each stage.

 

Example of using Template in Prototype

In response to a blog post by Ray Camden about jQuery and duplicating form fields, I put together an example of using the Template class in Prototype. As an added bonus, I designed this example to also handle form resets and to feature a controller based design. You can click here to view a demo of the example in action. Read more to get the break down of the code.

 

CFGrid Displays No Data Until Sort

So, another annoying bug, but at least I found a solution this one. I'm using Prototype and trying to get CFGrid running. Things went OK except that when I made a grid, it would load looking like the example to the left; no data listed. If you clicked on the "Students" header, you'd get the full list of students like the example on the right.

I was finally able to find an article in the House of Fusion mail archive that described no only the problem, but a solution:

Solution! After tearing the Javascript apart for both libraries, I found the problem. Both libraries use a function called "defer", which basically just delays performing that action until the interpreter's callstack is empty. My solution then was to change the name of this function in Prototype and then just change the name wherever Prototype references it also. None of the Prototype plugins I have use the function, so it's seems like it's pretty low-key.

So I quickly did a find and replace and changed Prototype's "defer" to "pdefer" and things started up fine.

 

Javascript Abstraction in ColdFusion: Pro or Con?

There is an interesting article up on Ajaxian.com today discussing the pros and cons of Javascript abstractions. It's aimed squarely at the root of an issue that I have with ColdFusion 8's Ajax and Javascript integration: abstractions are easier and save time, but do you loose something by giving away that control? I heard Andy Powell give a talk at CFUnited in 2007 about the (then) upcoming release of ColdFusion 8 and its Ajax and JS support, where he asked the room to raise their hands if they liked Javascript. Those few of us that did got some weird looks from the crowd... how weird: people that use a technology might actually like it?

I like Javascript, and I don't think that thats weird. If I need FCKEditor in ColdFusion, I still use FCKEditor, rather then the new tags. If I need ExtJS, I still use ExtJS rather then the new tags. Why? Because I know that I can program better for my situation then Adobe. Its not that Adobe's code isn't good, its just that they have to program in such a way that it works for everyone, and that always creates bloat. Always.

Using <cfwindow> will save you some time, I'm not saying that it wont, but its going to add overhead that might not intend. You might not ever notice that overhead, and thats fine, but what happens if its a problem? Ultimately you'll have to go find someone that actually knows (and probably likes) Javascript to fix the problem for you. Why not get that person to write it in the first place?

Where would you draw the line? The purist in me says "Code it straight in JS and don't mess around." while the realist in me says "If most people don't need to rework the tags, then its working fine." Do you think abstraction can come back to bite you, or is it just a time saver?

 

More Entries

Jon Hartmann, July 2011

I'm Jon Hartmann and I'm a Javascript fanatic, UX/UI evangelist and former ColdFusion master. I blog about mysterious error messages, user interface design questions, and all things baffling and irksome about programming for the web.

Learn more about me on LinkedIn.