Is ColdFusion's GetPageContext().Forward() Method Worth Using?
Posted November 3, 2006 at 8:33 AM by Ben Nadel
My traditional form-based-page model is such that a form submits back to itself for data validation and manipulation. If all goes well, I perform a CFLocation tag to send the user to either a confirmation page or some other type of "success" page. This works great. The only issue is that it involves going back to the browser. CFLocation sends a 302 response code back to the browser requesting that the browser then redirect to the given Url. This is a tiny interaction, bit if you are looking for extreme optimization, this can be slow.
The beauty of the Forward() method in ColdFusion's page context (via GetPageContext()) is that it stops the current page execution and "forwards" the current response to another part of the application (ie. the url you pass in). It doesn't have to go back to the browser at all. At first, this seems really snazzy and upon testing appears to be a fraction of a second faster. But, is this fraction of a second in performance worth the baggage that comes with it?
I guess it's a philosophical argument. I say NO, that it is not worth it. These are my reasons:
- Once on the success page, there is no visible URL change for the user / browser.
- Once on the success page, if the user were to refresh the page, the browser would try to resubmit the FORM data as it thinks you are still on the same page.
To me, these things are just not worth it. But again, this is philosophical. I am sure there are plenty of people that would argue that when a user refreshes a form confirmation page, the browser SHOULD resubmit data. They might also argue that "success" page shouldn't be a different url, that it is merely a different "phase" of the current form. Oh well, to each his own. At the very least, it was nice to experiment with.
Index.cfm Form Page
- <!--- Kill extra output. --->
- <cfsilent>
-
- <!--- Param form methods. --->
- <cfparam name="FORM.submitted" type="numeric" default="0" />
- <cfparam name="FORM.forward_type" type="string" default="forward" />
- <cfparam name="FORM.name" type="string" default="" />
- <cfparam name="FORM.hotness" type="string" default="" />
-
-
- <!--- Check to see if the form has been submitted. --->
- <cfif FORM.submitted>
-
- <!--- Set up URL for forwarding. --->
- <cfset strUrl = "./confirm.cfm?name=#FORM.name#&hotness=#FORM.hotness#" />
-
- <!--- Forward to success page. --->
- <cfif NOT Compare( FORM.forward_type, "forward" )>
- <cfset GetPageContext().Forward( strUrl ) />
- <cfelse>
- <cflocation url="#strUrl#" addtoken="false" />
- </cfif>
-
- </cfif>
-
- </cfsilent>
-
- <cfoutput>
-
- <h2>
- Page One : Index.cfm
- </h2>
-
- <form action="#CGI.script_name#" method="POST">
- <input type="hidden" name="submitted" value="1" />
-
- <label>
- Name:<br />
- <input type="text" name="name" value="#FORM.name#" size="30" /><br />
- </label>
- <br />
-
- <label>
- Hotness:<br />
- <input type="text" name="hotness" value="#FORM.hotness#" size="10" /><br />
- </label>
- <br />
-
- <label>
- <input type="radio" name="forward_type" value="cflocation"
- <cfif (FORM.forward_type EQ "cflocation")>checked="true"</cfif>
- />
- CFLocation
- </label>
-
-
-
- <label>
- <input type="radio" name="forward_type" value="forward"
- <cfif (FORM.forward_type EQ "forward")>checked="true"</cfif>
- />
- Forward()
- </label>
- <br />
- <br />
-
- <input type="submit" value="Submit" /><br />
-
- </form>
-
- </cfoutput>
Confirm.cfm Form Confirmation Page
- <cfoutput>
-
- <h2>
- Page Two : Confirm.cfm
- </h2>
-
- <p>
- I agree, #URL.name# was a definate #URL.hotness#!
- </p>
-
- </cfoutput>
Reader Comments
Hi Ben,
Point 2 is the killer. My old procedural controller was queue based. It would undertake an action within a while loop until the queue was empty, so all you needed to do to go from form processing to list display was to add an If FormValid THEN <Add UserList to controller queue>.
It was great until I realized that refreshing the list added another new instance if you'd just filled out an add form.
:-<
Pete,
Exactly. That's why I think for me, this is not going to be a solution that I can really use.
Good point, Ben. I also find the confirm page is easier to develop and debug when I can call it directly from the browser.
The only advantage to server-side redirects I've found is the ability to see debugging information in the browser after you submit the form. I found a way around that problem with a custom tag.
http://pmcelhaney.weblogs.us/archives/cf-debug-tip
Patrick,
True, the page is MUCH easier to debug when you can call it directly from a browser.
Thanks for the link as well.
I too like to use self-posting forms. My issue is that after a sucessful validation and the following cflocation the form scope is lost for the confirmation page. How do you get around that?
dickbob
DB,
Most of the time I do not need the form data on the confirmation page. However, if I do need some of the information, I generally pass it through the URL or in a uniquely key'd session object (and then just pass the unique key in the url).
Yes, I too put the form data into a session object to get it to persist through to the cflocation page. I tend to use a structure name based on the form id but using a unique id that is passed through in the URL is an idea I'll have to consider.
Thanks for sharing your technique.
dickbob
Hi Ben,
We had just an issue on one of our CF7 Hosting Servers where the server was getting out of memory and the logs showed a template that was using the getPageContext().forward() method.
According to the following technote, after the forward method a cfabort should be used or at least no output should be generated.
http://kb2.adobe.com/cps/401/kb401382.html
Don't know if later Versions of CF are affected too.
