Have you ever been logged into an application and had your session timeout, then when you log back in you are returned to a different place altogether?

This article deals with a way to mark where a user was in your application and return them to that location when they log back in. It also allows a user to deep link into an application. IE when they have a bookmarked link instead of being passed to the home page, they are passed through to their original destination.

[More]

One of the best practices that I've been using more and more is ColdFusion's ability to add CFC object references to scopes. By this I mean that it is possible to create a shorter friendlier scoped variable that you use to reference your CFC's.

In your Application.cfc you can map out all your CFC references, this gives you a much shorter variable name to type each time, and it caches the CFC.

Put any references like this in the 'onApplicationStart' function. You do not need to lock the scope in this function, and if the code within it does not run successfully then it does not continue running the application. It will try again on the next page request.

The caching functionality here is great, not only will Coldfusion create a handy short name for CFC, but it will actually run through the code, and stop on any errors. If you deliberately introduce a code error into one of your objects you will see the Application halt and show you the error. For me this is reason enough to move all my business logic into CFC's. This essentially means that it is not possible for a user to get part of the way through a application and find an object based error.

Using this in conjunction with a framework such as FuseBox allows you to load, parse and cache the CFC object, all before your actual display layer has been invoked.

The example below uses the FuseBox function 'onFuseboxApplicationStart' of starting an Application.

Changing the 'fusebox_parameters.mode' value allows you to set this caching at an environmental level, so no caching for development, or caching for live

One of the more common tasks in ColdFusion development is passing variables through the URL string. We are all familiar with the idea that the question mark (?) denotes the url query string start, and that name value pairs are separated with the ampersand (&).

I usually avoid using this in display templates, as it isn't great exposing your internal site workings to customers, and with Fusebox it is very easy to pass the URL variables to an "act_" template and remain hidden.

What happens when you want to use dynamic url variables with a URL re writing application like Isapi re write? I've been using Isapi re write in some FuseBox framework application, and it is relatively easy to set up a rewrite rule, as shown below.

Where the url /home/ would actually serve up the content specified in the fuse specified. But this is hard coded. What about dynamic variables?

We can create a regular expression to handle the translation of the variables.

We use a similar URL, but append the dollar ($) 1 = dollar ($) 2 string. In the re write rule we specify that appended variables are transposed into the string using the slash (/) as a separator.

So as an example we could pass a product id of 24 into the rule like this:

It would be rewritten to the more familiar url string. A handy way of continuing to mask the url.

One of the ideas that we have been throwing around the office is creating a platform that will create the form-validation-database cycle automatically. Something akin to ORM, but not. ORM looks good, but we want more control over what is happening.

In this article I am exploring the idea of automatically creating JQuery validation from a simple Coldfusion input. In this case a list of required fields. I'll say up front Ray Camden's blog entry on Jquery Validation (http://www.coldfusionjedi.com/index.cfm/2009/2/10/An-Introduction-to-jQuery-and-Form-Validation-2) has been an invaluable help.

The principle behind this is that you can create a generic validation object routine, and simple provide it with a set data object (list or struct, haven't decided yet) and have it match against a form and validate it. So with that in mind we will create a simple form.

As you can see from above, this is a simple form. Next we will include references to the Google code repository for the AJAX library, and out JQuery validation plugin. Next we have the JQuery script to validate our fields. Firstly we create a list of the fields that are required. By doing this it is incredibly easy to add another required field to the model. The next phase of this will probably accept a structure rather than a list, in that way I can combine field lengths and any other custom criteria, rather than merely the fact that it is required. The JQuery validation starts off in exactly the same way as usual, we create a function to catch the validation request, and use the id of the form as the reference. We declare the error container style of "#error". Next we loop over our list inside the "rules:" element. This creates the required rules for each field. I've also added a basic check for the value 'email'. This will create an email validation rule. Next we create custom messages in the "message:" element. Again this catches the email value and adds an appropriate message. Lastly we can create a style for the #error container we declared above.

This creates a totally dynamic validation routine - all fed from a list. I think it forms a good basis to build a more dynamic rules driven model, where you can set field lengths as well.

There is an example of the complete code here, along with a variation on the inline or external placing of the validation messages.

Follow this link for a demo of the JQuery validation model.

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.

I was discussing some ideas for an application framework this morning with the team, and one of the issues we hit upon was having a common directory for templates, but serving them up as if they were from a different directory.

The idea is to have one instance of a reusable skinnable template, that appears to live on several sites.

IE all the content lives in "webroot/content/templateName.cfm", but is actually served up by many sites, IE "127.0.0.1/site1/template1.cfm", "127.0.0.1/site2/template1.cfm" ... etc

In this way they can be re skinned or adapted as needed, and they aren't database driven. The main stumbling block for the discussion was the need to actually create blank versions of each of the named templates, in each of the sites, as ColdFusion server would error on the request.

I spent twenty minutes trying to work it so that my Application.cfc's onRequest or onRequestStart method would intercept the request before it was actually made, but that just wasn't working. My other idea was to use the onMissingTemplate method, but the server is only running ColdFusion 7, so that was a no go (I figured I could catch the missing template request and just re path it, although I'd have to assess if that was really inefficient due to almost every page request logging as failed).

My eventual solution was Isapi rewrite. I am re writing all the requests to the same template, and just passing in the template variable. In that way I can request pages that don't actually exist, but they appear in the url.

Create an index.cfm template like this:

For this example I am using the free version of Helicon's Isapi rewrite, you can get it here: Link to Helicons Isapi re write

In the example below I have altered the first page link to look like it is actually a .cfm template request, just in case you want the url string to have a .fileextension look to it.

So when you fire it up and test it you just see /page1, /page2 etc, and the pages don't actually exist.

I'm not experienced enough with Isapi rewrite to know if there is a downside to this, but bookmarking in a browser still works correctly, so I can't see an issues at present.