|By Charlie Arehart||
|May 30, 2002 12:00 AM EDT||
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:
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:
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.
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.
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.
|Patrick Correia 05/07/03 03:40:00 PM EDT|
According to the release notes for CFMX Updater 3, Macromedia claims this problem has been fixed.
|charles arehart 06/26/02 10:01:00 AM EDT|
Folks, just wanted to share a couple updates about the article. I had mentioned there were two "problems" in the release candidate of CFMX, which was the latest version when I wrote the article. Since then, the final version has come out, but the "problems" remain.
Actually, there is only one bug. The other is just something to understand.
The bug is that if you try to do a forward from a page that's a FORM action page, it fails with an error "err.io.short_read". That is a recognized (and very unfortunate) bug, that perhaps we can hope will be fixed in some sort of patch or service pack.
The other problem I'd mentioned, that FORM and URL variables weren't put in the REQUEST scope, is just something to understand. It makes sense in CF's design that this is not the case. The REQUEST scope isn't written to automatically at all. It's only for you to put things into it. But there is good news that mitigates this somewhat.
Let me first clarify that the only reason one would expect this would be from experience with either ASP or JSP, which put form posts and query strings into a "request" scope of sorts.
The good news is that, usually, any URL vars that exist on the calling page will be available on the page to which you forward. So it's not necessary to put them in the REQUEST scope to be able to access them (of course, with FORM vars not working at all, I can't vouch that this should work for them, but it's reasonable to expect).
But I've noticed one quirk: if the URL used in the forward has a query string specified, then that seems to cancel out the availability of the URL vars that were available on the calling page. It's as if passing any on the forward URL blocks any that had been passed to the forwarding page.
Oh well. Maybe that will be observed and resolved as a bug.
- Where Are RIA Technologies Headed in 2008?
- The Next Programming Models, RIAs and Composite Applications
- AJAX World RIA Conference & Expo Kicks Off in New York City
- Constructing an Application with Flash Forms from the Ground Up
- Building a Zip Code Proximity Search with ColdFusion
- Personal Branding Checklist
- CFEclipse: The Developer's IDE, Eclipse For ColdFusion
- Has the Technology Bounceback Begun?
- Adobe Flex 2: Advanced DataGrid
- i-Technology Viewpoint: We Need Not More Frameworks, But Better Programmers
- Web Services Using ColdFusion and Apache CXF
- Passing Parameters to Flex That Works