Not sure about ASP but <cflocation> is SERVER side redirection. The client never knows there has been a redirection.
Brian Knott -----Original Message----- From: Joel Nath [mailto:[EMAIL PROTECTED] Sent: Tuesday, 19 August 2003 1:51 PM To: CFAussie Mailing List Subject: [cfaussie] RE: what's inside CFLOCATION? (was "removing back button...") Hi Barry, try the following... <CFSCRIPT> request.myvar = "barry"; getPageContext().forward("yourtemplate"); </CFSCRIPT> any CF variables created on the starting page can be made available on the page to which control is forwarded. The only requirement is that they are only made available if they are placed in the REQUEST scope. Then they are available in the called page also in the REQUEST scope. also if i am not wrong response.redirect works slightly differently to cflocation but both do client side re-directions cheers joel -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Beattie, Barry Sent: Tuesday, 19 August 2003 10:15 To: CFAussie Mailing List Subject: [cfaussie] what's inside CFLOCATION? (was "removing back button...") Hi All just wanted to check: is CFLOCATION just "Error 302 page Moved Temporarily. new url='...'" which is equiv to ASP's response.redirect, yes? my main question is: is there a CF version of ASP's server.transfer (which works differently)? <quote src="www.devguru.com"> ***useage: Server.Transfer(Path) *** The Transfer method allows you to transfer from inside one ASP page to another ASP page. All of the state information that has been created for the first (calling) ASP page will be transferred to the second (called) ASP page. This transfered information includes all objects and variables that have been given a value in an Application or Session scope, and all items in the Request collections. For example, the second ASP page will have the same SessionID as the first ASP page. When the second (called) ASP page completes its tasks, you do NOT return to the first (calling) ASP page. </quote> thanx barry.b -----Original Message----- From: Beattie, Barry [mailto:[EMAIL PROTECTED] Sent: Tuesday, 19 August 2003 9:56 AM To: CFAussie Mailing List Subject: [cfaussie] Re: removing back button... this is to stop multi form submits, yes? one handy trick we used to do was to response.redirect (Ooops! CFLOCATION) the browser to another page after the form had been processed. sure they could go back and back but you could do things like check if the http_referer was or was not the page with the form and deal with accordingly. cheers barry.b -----Original Message----- From: Gary Menzel [mailto:[EMAIL PROTECTED] Sent: Tuesday, 19 August 2003 9:10 AM To: CFAussie Mailing List Subject: [cfaussie] Re: removing back button... > give up and code your app to not require it. Oh yes - I forgot that mantra. But agree with it totally. The amount of effort that goes into attempting to "break" the default browser functionality just isnt worth it. The fundamental issue that faces programmers in using the web to write applications is the client/server/stateless paradigm. The web is not meant for applications - it is meant for delivering information. You can write applications - but you keep these fundamentals foremost in everything you do then you will be much better off. Gary Menzel Web Development Manager IT Operations Brisbane -+- ABN AMRO Morgans Limited Level 29, 123 Eagle Street BRISBANE QLD 4000 PH: 07 333 44 828 FX: 07 3834 0828 **************************************************************************** If this communication is not intended for you and you are not an authorised recipient of this email you are prohibited by law from dealing with or relying on the email or any file attachments. This prohibition includes reading, printing, copying, re-transmitting, disseminating, storing or in any other way dealing or acting in reliance on the information. If you have received this email in error, we request you contact ABN AMRO Morgans Limited immediately by returning the email to [EMAIL PROTECTED] and destroy the original. We will refund any reasonable costs associated with notifying ABN AMRO Morgans. This email is confidential and may contain privileged client information. ABN AMRO Morgans has taken reasonable steps to ensure the accuracy and integrity of all its communications, including electronic communications, but accepts no liability for materials transmitted. Materials may also be transmitted without the knowledge of ABN AMRO Morgans. ABN AMRO Morgans Limited its directors and employees do not accept liability for the results of any actions taken or not on the basis of the information in this report. ABN AMRO Morgans Limited and its associates hold or may hold securities in the companies/trusts mentioned herein. Any recommendation is made on the basis of our research of the investment and may not suit the specific requirements of clients. Assessments of suitability to an individual's portfolio can only be made after an examination of the particular client's investments, financial circumstances and requirements. **************************************************************************** --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/
