Now that we can talk freely about ColdFusion MX, I want to share something new that you likely won't hear much about...

...but that I think stands to be an important feature: server-side redirects, or "forwards." It's something CF has long been missing, and an improvement over CFLOCATION. The thing about a forward is that it's quite different from, and in most ways much better than, a CFLOCATION. We've all used CFLOCATION to transfer control from one CF page to another. But did you know that it performs a client-side redirection? The user doesn't see it happen, and maybe you never noticed it. It's done by CF sending a special HTTP header to the browser. Maybe it never mattered to you, but this behavior has some negative implications.

The most important one is that data that's passed into the calling page isn't available to the called page. In other words, if template1.cfm is called as a form action page and is passed several form variables, when you do some processing and then use CFLOCATION to transfer to template2.cfm, you won't have access to those form variables in template2.cfm (see Figure 1).

Many have tried to get around this challenge by passing the form variables on the query string in the CFLOCATION's URL, or by setting the variables into the session scope. Still another approach is to CFINCLUDE template2.cfm instead of using CFLOCATION to call it, or perhaps call it as a custom tag. Each has its place. But there may be times when for modularity, encapsulation, or other purposes, you do indeed want to transfer control to the next program, but also pass along all the data that was sent to the caller. Further, you may want to pass along any data created in the calling page (template1.cfm in our example), such as queries that were executed or the result of any other operations (such as a CFHTTP, CFLDAP, etc.). Again, this data won't be made available to the called page with a CFLOCATION. But it can be made available in a server-side redirect.

The Power of Server-Side Redirects
Server-side redirects solve this problem. Data in the calling page can be made available to the called page. ASP added this feature with their server.transfer() method (whereas their response.redirect() acted like our CFLOCATION). And servlets and JSPs have long had the concept of a "forward."

Indeed, because CFMX is based on an underlying servlet/JSP engine, we now have exposed to us the same capability. To do it, we simply leverage a new function in CFMX, which is in fact exposing to us the servlet PageContext that allows servlet and JSP developers to use a forward. In fact, the syntax to do so may look a lot alike, but it's all CFML:

<CFSCRIPT>
getPageContext().forward("relativeURL");
</CFSCRIPT>

This doesn't have to be done in a CFSCRIPT, but it works a little more easily this way. Still, for those who don't want to remember all this detail, I've created a simple custom tag called CF_FORWARD that can often be used in place of CFLOCATION. You can find it in the Macromedia Developer Exchange, at http://devex.macromedia.com/developer/gallery/info.cfm? ID=C0DB78BB-617C-11D6-840300508B94F380& method=Full.

An example of using it might be:

<CF_FORWARD URL="relativeURL">

Note that in both examples the relative URL can be any CF template (and even a JSP template if it's been placed within the CFMX directories where your CF templates are located). Note also that you can pass a query string on the URL, just as you can in CFLOCATION.

Sharing Data Between Pages
I said earlier that one of the key new features is that you can share data between the calling and called pages. The only trick is that the variables to be shared must be placed in the REQUEST scope. This scope has been available to us in CF for a while and was used previously for sharing data with custom tags.

Now, if you place some variables into the request scope, or perhaps create a query on the calling page with NAME="request.queryname", then those same REQUEST variables will be available (using the same REQUEST scope and variable names) in the called page. In fact, one feature I added to my custom tag is that if you use the LOCALVARSCOPIED="yes" attribute, it will automatically copy local variables (such as queries created on the page with no specific scope or the VARIABLES scope) into the REQUEST scope before calling the forward.

Note, too, that this means that CF and JSPs/servlets can also transfer control between each other and access each other's REQUEST scopes (although the REQUEST scope in JSPs and servlets means a bit more than it does in CFMX).

This ability to do server-side redirects is also the key to doing true Model-View-Controller (MVC) style design of your applications. That's a subject beyond the scope of this article, but for those who understand it, it opens very interesting doors to us. I hope more people in the CF world will investigate this possibility now that it's closer to a reality.

Not Perfect
Sadly, the forward method as currently implemented (in the preview release candidate, or RC) isn't perfect for a couple of reasons.

First, and perhaps challenging to those with servlet/JSP experience, I've found that unlike JSPs and servlets (for those familiar with them), in CFMX the REQUEST scope of the caller doesn't automatically include the FORM and URL variables that might have been passed to it. The good news, however, is that any URL variables available on the calling page are also available on the called page. In this respect it works like custom tags.

The second problem is more serious. I've found (again, in the RC) that if I try to do a forward on a page (or within the custom tag called from a page) that is itself a form action page (has "form." variables available), the forward fails with an "err.io.short_read" error. That's strange and a real bummer. Until that's resolved, you won't be able to forward from a form action page. I've got the custom tag detecting and stopping before that error.

This is real tragic, though, for using MVC style design for form action pages. I hope it's either fixed in a later RC or can be fixed before the final production release.

A Bright Spot
Despite the bad news, there's a piece of really good news. Many have surely been hassled by the fact that if you set a cookie before doing a CFLOCATION, it never gets set on the client. But I've found that if you set a cookie before doing a forward, it is indeed set to the client. It seems like magic, but JRun's documentation suggests that the JSP:forward tag has always had this behavior. So it's just another benefit we leverage since CF is based on the underlying JSP/servlet engine.

Other Considerations
Finally, there are some things to be aware of with using a forward. When you do a server-side redirect, since by design it doesn't send a redirect through the browser, the URL shown to the user will still be that of the page they requested that did the forward, not the page to which control was redirected. In our example above, the URL will show template1.cfm. This has several ramifications (challenges if they bookmark it, possibly unexpected results for you or them if they hit the refresh button).

These are issues well discussed in the literature regarding the use of forward in JSPs and servlets, and I imagine ASPs since the introduction of server.transfer(). Over time, we'll all come to learn the same lessons and find the strengths and weaknesses of this approach.

It may also be interesting to see if the Fusebox community adopts this new approach in their design, given that it already attempts the kind of encapsulation and decoupling that is a hallmark of MVC design.

Of course, all this shouldn't challenge the Macromedia mantra that in CFMX one need not learn Java. No, one need not. I'm just pointing out that doors are opening that may offer interesting rewards for those who explore them - and perhaps eventually those discoveries may trickle into more abstractions for the CFMX masses.