gregs

I have been updating a bunch of code recently to make use of the new features in Prototype 1.6 and one of the great additions in this release was the introduction of Automatic JavaScript response evaluation. This allowed me to improve on my session checking code without having to fuff around with the response information sent back to the client. The problem was with XHR requests: i.e. if the user initiated such a request when his session had expired, then usually the response would fail or worse just hang.

The snippet below shows my new session checking code.

The trick is to intercept the call when you do your session checking at the back end. Let's say you have a fuseaction called login.login (see below and yes this is fusebox 3 :S) where you display the login form when a user is not logged in, this is where I inserted the check for an XHR request, by looking at the http headers sent along with the request. The key here is a new header attribute passed in with Prototype "X-Requested-With". If this attribute exists then I know it's an XHR request and I can create a custom JSON header with an error struct that holds a key called session with a value of timeout. All I then need to do is encode the struct as JSON and pass that encoded struct back to the browser.

Now let's jump back to the JavaScript code and take a look at the onComplete function again:

If there's a JSON object and it has a key of session then I call my setSessionExpired function which redirects the users. Now the json session key only exists in these situations since the call normally just passes back the result of the call.

Just wanted to let folks know, and with trepidation, that the 0.1 release of Stubbie is available for download from the project page. I have also added a few blog posts to the project:

• Basic install instructions
• Links for feedback, issues and suggestions

Just a quick note to let folks know that I have created a small project on RIA Forge called Stubbie. Inspired by a feature in Rails, Stubbie basically creates a set of test stubs for your apps CFCs. I have set up specific blog for it over at RIA forge to keep everything in one place, but will post updates here as well.

Also there's no code yet, still one or two things I need to sort out before I'll make the first 0.1 release.
I'd just like to thank a few people who helped get this project of the ground:

Special thanks must go to Stephen (Spike) Milligan for allowing me to use his CFCDoc code which allowed me to quickly build the project without having to worry about the File System and CFC parsing.

Seth Petry-Johnson also deserves a special mention for allowing me to use his VarScopeChecker.cfc as part of the project so that we can all benefit from a var scope unit test.

A client recently decided to start storing all of their images in a database and usually we would point the image source to a cfm page, where we'd do something like this:

Which worked nicely until I read about some performance issues with http calls and the cfdocument tag. Zac (yes his name pops up a lot in this blog), put me onto directly embedding the image into the source, like such:

No need to make a http call to display the image anymore.

A while back I was tinkering with converting SVG output to PNG using Batik, but I was not having much luck with it as it seemed that the Batik jar files that come with CFMX were out of date or plain missing some methods. I gave up, but a colleague of mine, Zac, picked up the baton and has come up with a solution. Now before you dive in and follow these steps, bare in mind that this is just our first day of using this, so even though Flash forms still appear to be working there may well be cases that we haven't stumbled across yet, where our changes have broken CF (and for the record we don't use Flash Forms, Charts or anything flex related). So in other words use this 'tip' with caution!!

Still reading? Awesome, so here's what we came up with, first off the Batik version that ships with CFMX 7 is 1.5.1, so head over to the Apache Archive and download the 1.5.1 version from the archive. In essence we'll be replacing like for like. Once downloaded locate the the cfforms\jars folder in your CFMX installation (on windows standard you'll find it under C:\CFusionMX7\wwwroot\WEB-INF\cfform\jars).

Before continuing make sure you back up all of the batik files located there (i.e. batik-awt-util.jar, batik-css.jar, batik-ext.jar, batik-transcoder.jar and batik-util.jar) and move them out of the CFMX install folder. Once done, just extract the lib and extensions folder as well as the batik-*.jar files into cfform\jars folder. Once done all you need to do is restart CFMX and the updated JAR files will load (you may want to consider to launch CFMX in debug mode to make sure nothing bad is happening).

Update

Barney Boisvert got in touch to let me know that he is done something similar, but used a newer version of Batik. Follow the link to see his posts on the topic.

I have been spending a few days building a bunch of web services for a client, however whenever I made a change to the web service itself the only way I could get that change to be reflected was by either waiting or re-starting cfmx. I did remember a post a while back that showed a better way. Finally I had enough today and went looking for the solution.

For my own benefit here is the code required to refresh the stub:

Big thanks once again to Brandon Purcell for sharing this with us

Update

Or I could have just looked in the CF Administrator (if you are using 7.0.1) under Data & Services and looked at the registered web services and refreshed them there...

A wee while back the Mac PowerBookPros received a JVM update. This brings it up to version 1.5.06, which is fabulous, but of course stops you from being able to run ColdFusion. Thankfully the JVM upgrade leaves the old versions on your system. The simple trick to get your CFMX installation to wok again after the upgrade is to run the start up script from the console with the path to the old JVM like such:

I just started using MSDE for local development again and after creating my first DSN through the ColdFusion administrator I encountered the following problem:

First thing I checked (well second after making sure I had provided the right connection details) was to see if anything was listening port on port 1433 by using the handy "netstats -a" command. And there wasn't, so a quick Google search turned up this gem from Robi Sen. Sadly this tool didn't help me as apparently my version didn't need it, but a comment did point me to a another link. But sadly it didn't help me either, but the comment did give me an idea. When I went to check my network set up for MS SQL server, sure enough TCP/IP was not listed... What followed was a moment of banging my head sharply on the table.

Right changes applied, restarted the server, verify connection and...

Well this one only took a few seconds to fix: Windows Authentication only was enabled! Simply open the properties of your server once more, check the security tab and you should see that the option for Windows Authentication is selected. Just change that to SQL server and Windows and you are ready to go...

I guess this is very much a case of damned if you do and damned if you don't for Microsoft as they seemed to have tightened up the security for MS SQL server (I won't even go into the nuisance of trying to install MSDE and being prompted to set an SA password before starting with no indication how to do so), but surely we should be given the option at install time to set these things? Or maybe it's just the MSDE?

Here is a handy little script that I stumbled across a while back (probably on a mailing list), sorry I can't remember who posted it, but for posterity here it is:

UPDATE

It was from Pete Freitag's site that I gleaned this tid bit of information and Niklas over at Primsix was kind enough to also point out that he put together a graphical version.

Just the other day I installed Cold Fusion Enterprise on one of our web servers hosted externally. After the re-boot I fired up a browser to test the installation. Alas the server wouldn't execute .cfm file extensions, instead offering me the chance to download these. The problem was down to the installation program not mapping .cfm extensions to the Application settings. You can check the mappings and fix this by carrying out the following steps:

1. Start up IIS MMC.
2. Right click on your site and select Properties.
3. Change to Home Directory, and in the Application settings box, click on the configuration button.
4. Under the Add mapping tab yo can see all the file extensions that your server can interpret. If .cfm is not listed, this is the reason your server s not executing the Cold Fusion templates.
5. Click on the Add button and complete the dialogue. Under executable specify the path and file name for your CF server executable, usually <drive letter>:CFUSION\Bin\iscf.dll. Next specify the file extension, i.e. .cfm and make sure that the option for Scrip engine is ticked.

Repeat the same step for the file extension .dbm, if it's not listed either. Once done click on OK and OK again to return to the console. Fire up your browser and try it again. The files should now execute.