I ran into a problem recently where a completely valid XHTML 1.0 transitional site was rendered incompliant by the addition of <cfmenu>. It seems that <cfmenu> causes compliance to fail in two ways:

First, it adds JavaScript to the "OnMouseOver" and "OnMouseOut" attributes of its menu items. To be compliant, it should be adding them to the "onmouseover" and "onmouseout" attributes. There's an easy fix to this. Inspired by Ben Nadel's post on altering the output of the writeToBrowser feature of <cfimage> I just used <cfsavecontent> to capture the menu, and then alter it, as listed below:

<cfsavecontent variable="menuContent">

<cfmenu name="menu" type="vertical">

<cfmenuitem name="home" href="index.cfm" display="Home"/>

</cfmenu>

</cfsavecontent>

<!--- These calls help bring page to XHTML compliance. --->

<cfset menuContent = Replace(menuContent, "OnMouseOver", "onmouseover", "ALL") />

<cfset menuContent = Replace(menuContent, "OnMouseOut", "onmouseout", "ALL") />

<cfoutput>#menuContent#</cfoutput>

But that doesn't hit the other problem, which is that any of the Ajax capable tags seem to add the following bit of code to the top of a page:

_cf_loadingtexthtml="<div align='center'><img src='/CFIDE/scripts/ajax/resources/cf/images/loading.gif'/>"

This screws up compliance on two fronts:

1. The div created in that code isn't closed.
2. The img created in that code doesn't have a alt tag.

Now the interesting thing here is that isn't actually a div that's created, it's only JavaScript that will at some point create those elements. I think technically the compliance test is falsely marking this as a violation. But try explaining that to a client who demands compliance without understanding the theory behind it.

Anyway, I can't find a single way around this. Using the OnRequest method of application.cfc was my best bet. I figured I would use to call <cfsavecontent> and replace the offending code like I did above. Unfortunately, this spot of code is directly written to the buffer when <cfmenu> gets called.

I also tried a few getPageContext() functions, but to no avail. I'll be stuck trying to explain this to the client. In the meantime, I filed a bug report with Adobe.

I've been having an issue with a quick and dirty development server I setup for a project. I couldn't get Verity operations to run. I checked and low and behold there was no Verity Service installed. I reinstalled ColdFusion, but still no "ColdFusion Search Service" showed up.

I tried the super secret verity_uninstall and verity_install bat files, but still no joy.

Then I tried what I should have thought of in the first place. I right clicked verity_install.bat and chose to run as administrator. That did the trick; Verity is now completely working.

Nathan Mische asked a really good set of questions in response to my code review presentation posting. I figured that I would give a longer answer than really works in a comment.

First it's important to point out that formal code reviews are part of a suite of quality assurance techniques. They do not preclude the use of any other, including application design, informal code reviews, testing, etc.

But formal code reviews, a whole bunch of people looking at all of the code, and then having a long meeting discussing it, are relatively expensive. They take a good deal of time from many people who are probably working on their own code, and incurring the cost of context switching by doing so. So my guideline for code reviews is once per major revision of the application. Basically, if you spend a few days doing an update on an application that has already been reviewed, then you probably don't need a formal review. If you and a team of developers spend 4 months doing a revision to the code, a formal review is probably in order. Those are the extreme cases; your organization will have to choose where in between to draw the hard fast line.

As for when to do them… We at Wharton do them basically right before the application moves from development to production. This is also the time when we try the application out on the staging server. The timing is dictated by how we've mandated code reviews. To get your application on our production ColdFusion servers you must go through a code review.

Is that the best time? I'm not really sure. I think if you design correctly, unit test, informally review code, and get user feedback from your clients, then it is the right time to do the review. But we don't always do all of that so I get the subtle feeling that earlier might be better, but we'll just have to deal with the timing forced by our mandate.

Anyone else have any opinions on this?

Back in June, I gave a presentation on formal code reviews to the Philadelphia CFUG.

I've had it ready to share for a while, but I hadn't gotten around to it until now. Enjoy.

Code Review Presentation Given to Philadelphia CFUG

Dave Konopka has a post over at his site about a ColdFusion position that is open at Wharton Computing at the University of Pennsylvania, in Philadelphia PA. He's looking for a junior level ColdFusion developer, but will consider hiring a PHP, Ruby or .Net developer and retraining.

I had the pleasure of working with Dave for a little over a year and half, and let me say that Dave's an amazing guy with which to work. Also, he took the .Net programmer retrained in ColdFusion route, so he's not fooling around about accepting other technologies. So if you're even thinking about it, I say take him up on his offer and drop him a line.

See his post for details.

If you want to see what kinda stuff we're all into at the Wharton School, check at the Wharton Computing Developer's Center.

I updated the blog here to Movable type 4. It was extremely painless. It even inspired me to fix a whole bunch of stuff that was wrong with it. Specifically email subscriptions to entries now work.

The new backend it very cool. It took me a little getting used to, but now that I've got the hang of it, I'm extremely pleased. There's a lot of new features, and I'm looking forward to giving them all a try.