Thought Delimited

Before I went on vacation last week, I read a blog post by Ben Nadel where he demonstrated code for stepping through the search path of a jQuery selector in order to debug the selector. As Ben pointed out, if you make a mistake in your selector, it will fail silently, making it hard to figure out exactly where you went wrong.

In the comments to the blog post, Shayne Sweeny pointed out that you can run jQuery commands directly from the blue command prompt in the Console view of the Firefox Firebug plugin, like so:

I like this technique because it lets me write any jQuery code I want (selectors don't usually give me problems, it's the DOM traversing that sometimes trips me up), and I can use it on any of my pages that use the jQuery library without adding extra code to the page.

But what if you're trying to troubleshoot a jQuery command in a browser other than Firefox (for some reason)?  Well, I did a bit of tinkering and came up with a bookmarklet that does something similar.  If you're not familiar with bookmarklets, they are bookmarks you can add to your browser's bookmark collection that run JavaScript code instead of opening up a different web page.

The bookmarklet I created adds a <div> at the top of the page with a text input and three buttons.  Any jQuery command entered into the text box will be executed on the page and then recorded below the text box for reference.  Here's a screenshot of it in action in Opera:

It works in Opera, Safari, and Chrome:  I couldn't get it to work in IE 7 (surprise, surprise).

To use it, all you have to do is go into whatever browser you want to use it with and create a bookmark that has the following code in place of a normal bookmark URL:

javascript:var%20d=%20document.createElement("div");d.style.width="100%;";d.style.border="1px%20solid%20#ccc";d.style.margin="5px%200px;";d.style.padding="7px";d.id="jqtD";var%20t=%20document.createElement("input");t.type="text";t.id="jqtT";t.size="80";var%20b=%20document.createElement("input");b.type=%20"button";b.id="jqtB";b.value="Execute";var%20c=%20document.createElement("input");c.type="button";c.id="jqtC";c.value="Clear";var%20s=%20document.createElement("input");s.type="button";s.id="jqtS";s.value="Close";var%20bd=document.getElementsByTagName('body')[0];%20b.appendChild(d);var%20frst=%20bd.firstChild;bd.insertBefore(d,frst);d.appendChild(t);d.appendChild(b);d.appendChild(c);d.appendChild(s);jqtEvts();function%20jqtEvts()%20{$("#jqtB").click(function()%20{var%20tst=%20$(this).prev().val();eval(tst);$("#jqtD").append("<br%20/>"+tst);});$("#jqtC").click(function()%20{$(this).siblings("input[type='text']").val("");});
$("#jqtS").click(function()%20{$("#jqtD").remove();});}

...Just make sure to remove any spaces or line breaks that may have been introduced during the copy and paste process.

In case you missed hearing about it, Hal Helms, Brian Kotek, and Ben Nadel got together recently to do a podcast about the ongoing debate with doing object-oriented programming (OOP) in ColdFusion. Hal took the position that ColdFusion is not suited to doing OOP and that OOP is overkill for most ColdFusion applications, while Brian defended the use of OOP when used appropriately and judiciously, and Ben took on the role of the undecided developer.

I listened to the podcast this afternoon, and I thought it was a frank, rational, and realistic discussion about the issue (as I pretty much expected from these gentlemen). I encourage anyone who's got an interest in this topic to check out the podcast: you can download it from the following link:

http://epicenter-public.s3.amazonaws.com/ColdFusion-and-OOP--Match-Made-in-Heaven-or-Long-Road-to-Hell.mp3

Comments and further discussion about the podcast are being done using Google Groups, so if you have something to say on the topic, follow this link:

http://groups.google.com/group/coldfusionoo

Last year I wrote a ColdFusion application that included a page where an editor could take a list of short news abstracts and manipulate them (reorder them, place them in categories, add divider lines, create anchor links to highlighted stories, etc.) using a number of jQuery-powered JavaScript functions. It gives them a lot of control over the final layout, and they're pretty happy about it.

However, there have been occasions when this layout tool doesn't work at all. Why? Unclosed HTML tags in the abstract data.

The page they use to enter the news abstracts is comprised of several plain HTML text fields, a set of category checkboxes and two WYSIWYG textarea boxes (powered by JavaScript) for the abstract itself. I gave them the WYSIWYG boxes because I knew they would want to be able to do some basic HTML formatting on the abstract text (boldface, italics, etc.), and the WYSIWYG editors do produce solid, clean HTML.

What they do that gets them in trouble is they enter HTML tags (usually for italics) into the title form field, which is a normal HTML text field. Every once in awhile, they forget the closing tag or maybe just an angle bracket...the abstract itself saves correctly but when they get to the layout tool, that unclosed HTML tag messes up the entire DOM structure the layout tool is programmed to manipulate, rendering it non-functional.

They've now learned that when the header text of the various layout tools appears in italics, that usually means they've got an unclosed italics tag that needs fixing. It's easy enough to fix once they figure out which news item is responsible.

So a word of warning: if your JavaScript functions are designed to act upon HTML code that you yourself don't have complete control over (or the ability to make sure the HTML is clean and proper), consider the possibility that your JavaScript may end up breaking due to the content.

In my previous blog post, I mentioned running into a "weird issue" involving the comment subscription functions in MangoBlog. That functionality worked perfectly fine on my development machine, but when I uploaded everything to my site on a HostMySite shared server, I discovered that the database records for subscribers weren't being created.

After a lot of digging and experimenting, I tracked down the error. There are several places during the subscription process where variables are created using the <cfsavecontent> tag (the SQL for the record insert, the text of the email templates, etc.). When that code tried to run, I'd get the following error:

access denied (java.io .FilePermission C:\ColdFusion8\wwwroot\WEB-INF\cftags\savecontent.cfm execute)

Normally, that's the kind of error you get when access to a certain CF tag is disabled by your hosting provider. But I was able to write a simple .cfm page that used <cfsavecontent> and run it without any problems.

So I did some searching on Google and came across this Atlanta CFUG discussion thread:

http://www.mail-archive.com/discussion@acfug.org/msg05438.html

Apparently, there is some scenario (possibly involving sandbox security) in which <cfsavecontent> will not run inside of a <cfthread> tag. Since it's very likely that HostMySite has my site within a sandbox, I looked in the MangoBlog code for instances of <cfthread>, and indeed it turns out that the code events triggered during the subscription process were being processed through <cfthread>.

Rather than taking the time to figure out which events needed to be prevented from running inside <cfthread>, I simply added code to avoid that usage of <cfthread> entirely. (Please note that I'm not by any means an expert on MangoBlog, so don't take this as a recommended fix. And MangoBlog is designed to run on CF 7: the use of <cfthread> is optional, but from what I gather the blogging engine will use it if it's available).

When Adobe released the public bug tracker for ColdFusion today, I did take a brief look through it to see if this type of scenario was documented, but didn't see anything. There's no point in reporting the bug until I know what the exact conditions are that cause it to occur: maybe if I have some time, I'll set up sandbox security on my CF 8 developer box and tinker with it.

Anyone else (besides me and the Atlanta CFUG folks) ever run into this particular problem?

I decided, mostly on a whim, that my blog needed a new look. It hadn't changed much since I first launched it back in October of '07, and it looked pretty stark compared to many of the current blogs out there now.

I was aware that a number of fellow ColdFusion bloggers were using a ColdFusion-powered blog engine called MangoBlog, but I didn't know much about it until I downloaded it and started poking around. Installing it on my local development machine was a breeze, and I was impressed by the skinning and plugin features, so I decided to give it a shot.

Installing it on my actual website proved to be more of a challenge due to my hosting environment (a shared server on HostMySite). For one thing, the 50-second execution time limit imposed on the server prevented the MangoBlog installation code that copies data over from BlogCFC from completing, but I was able to hack the code in order to break up the import process into several steps. I also ran into a weird issue that prevented the comment subscription functions from working (more on that in a separate blog post), but I got around that as well.

The "skin" I'm using is a personally-modified version of one of the skins that comes packaged with MangoBlog, called "Glossy Blue." I added a picture of Yosemite Valley my wife took in the summer of '06 as the page background, used some CSS hackery to widen the content area and give the side column a different background color, and expanded the size of the calendar icons so I could include the year as well as the month and day. I may make a few additional tweaks, but overall I'm pretty happy with it.

There's a lot going on in the ColdFusion community now that ColdFusion 9 and the new ColdFusion Builder IDE are now in public beta. I'm eager to delve into both products (but especially Builder because that will hopefully benefit me immediately), so I expect I'll have a few blog posts about those.

The whole reason I started blogging in the first place was so I could share some of the things I've come up with coding-wise, techniques and thoughts that might be of value to others, so I hope to continue blogging in that vein.