There are several sites available detailing how to embed SWF Object's into your sites. By far the most reliable, and cross browser compatible without writing any form of Internet Explorer / Firefox hack is the SWF Object javascript plugin.

Adobe have a Developer Connection article detailing how the SWF Object javascript plugin works, http://www.adobe.com/devnet/flashplayer/articles/swfobject.html but it is six pages long, and seems to avoid any direct example of the most straight forward method of implementation. I am sure that it is all encompassing, but I was looking for a quick bullet point style guide.

So here it is:

1. Include the call to the Swobject Javascript library, don't host this yourself, just link directly to Google's code base.

2. Setup the flash variable scopes, this ensures that they exist, and it is a handly place to set global variables for your flash. I normally include this in the header of my frameworks.

3. Setup a div for your flashcontent. This is what will be displayed if you are not flash enabled. Ensure that your "No Flash content" either closely represents the actual flash content, or signifies a link to getting Adobe flash in some way.

At thsi point the "No Flash" content will be displayed on screen.

4. Lastly include the script to switch out the "No Flash content" with the actual flash.

This Javascript will over right the div (by id) and insert the flash object into it. Supply the path, the div ID to replace the content for, followed by the height and width values. Next is the Flash player version (set it to a higher number than the Flash player version for Non flash content testing). Next you include the variables scopes you created in stage 2, passing in any other values your flash content is expecting.

If everything is running correctly you can now see your flash content. Simply change the flashplayer value, 9 above, to something higher, for example 20 to see the non flash content.

One of the more recent additions to my Coldfusion frameworks is masking the more ugly URL's using Isapi rewrite. In this article I'll be using Helicon's Isapi ReWrite, but Apache re write works in much the same way.

Usually in your Coldfusion frameworks, most other technologies as well, you are passing around a variable or two to control the page content, and more often than not it is in the url. It never looks particularly clean if your URL has a long name value query string behind it, like this:

Cosmetic reasons

So for two reasons URL rewriting seems like a good idea.

Firstly to mask those ugly URLS with a url rewriter. On a basic level this will re write specified request to the URL you tell it to, taking your ugly list of name value pairs and changing it into a user friend URL. If you are pitching this to a client this looks a lot more professional.

Security reasons

Secondly there is an added security benefit here. The URL gives a lot away about a website, like what the code base is, and is potentially a window on the internal workings of a website. Take a normal FuseBox application for example. The normal URL might be:

From here it is very easy to start messing around with the controller names, trying to dig out an 'admin' controller, or other common function controller. Similarly adding values to pages where it is obvious a Query has been fired is an easy way of testing of the developer is using 'cfQueryParam', with potentially disastrous results.

Along the same lines it is quite simple to inject form values into the URL (like this http://www.mccran.co.uk/index.cfm/2009/7/30/Cross-site-Script-hacking-using-the-GET-method). By masking the URL and the values you make it considerably more difficult to do this, after all if you can see or get to the URL, how can you fool around with it?

So far I am implementing a rewrite script that will rewrite URLs into friendly strings, here is a modified version of the .htaccess file I'm using.

This code starts off by turning the rewriteEngine on, then setting the rewriteBase, this is typically your webroot, or the root of the site the file is for. Then it rewrites any URL params to the URL string.

The main part of the code is where we set individual rewriteRule's for each URL. The first example (home) looks for any URL requests to the 'home' string, and re writes this to the URL in the regular expression (index.cfm?go=controller.home). Pretty straight forward really.

There is a lot more you can do with this, and hopefully I'll get to explore rewriting in more depth in the future.

One of the more common problems with a ColdFusion application, especially when it starts to grow or involves more than one developer is variable scoping, and scope bleed through issues. More recently I have had to re examine the framework of an application, in an effort to track and eliminate any instances of this.

Not properly scoping a variable, IE:

Forces ColdFusion to add the variable to the 'variables' scope. This scope is available to the entire template. This is even more important when you consider CFC's and the potential damage that a leaked variable could cause. One of the major benefits of OO in ColdFusion is the encapsulation that it provides. As soon as you start declaring un scoped variables, then you lose that.

Mike Schierberl has quite an in-depth blog about this subject, http://www.schierberl.com, he goes into a great deal of depth about this subject, and he has built and maintains the varScoper project. The varScoper allows you to scan your code base for un scoped variables, and after a quick inspection of its output it seems very reliable. I'm not sure its 100% foolproof, but would be a valuable addition to a QA process.

Changes to the Var scope in Coldfusion 9

I am currently not using ColdFusion 9 in any environment; in fact my hosting company is still on 7! That said it appears that there are some significant changes to the Var scope in ColdFusion 9.

Ben Forta sums it up nicely here:

http://forta.com/blog/index.cfm/2009/6/21/The-New-ColdFusion-LOCAL-Scope

He does touch on an interesting point in the article above. I quite like the structured layout of a CFC, and part of that regime for me is declaring all the Vars at the top of a function. It sort of matches the layout of an Action Script class as well, declaring all your constants etc at the top of the script. It is also a very easy coding standard to adopt and enforce if you are part of a larger team.