We're only two months into 2002 and it's already shaping up to be a very busy year for ColdFusion development. I hope you're experiencing the same thing.

If so, don't forget we're here to help you with all your CF-related issues. This month I have two questions for you.

Q: I'm writing a CF app that needs to interface with another company's shopping cart. A user adds products to our shopping cart and when ready to pay for the products, we send the user to a payment processor for credit-card processing. When the purchase is approved, the payment processor sends the user back to our site using a URL we specify. The problem is this: when the user first comes back to our site, the cart is empty and the session variables seem to be lost. If the user clicks any links within our site again, the cart contents reappear. Any ideas?
A: I've encountered this situation before with an application I wrote for a client a few months ago. The problem is that the payment processor, after processing the transaction, is redirecting the user back to your site using a server-side redirect. Because of this, the user's browser is not sending the CFID and CFTOKEN cookies needed for session management to your site. However, once the user clicks again within your site, these cookies are available to your server. To solve this you need to include the values of CFTOKEN and CFID as part of the URL the cart will send the user back to.

For example, when your user clicks the "Pay" button on your site, you're sending the amount of the purchase and the return URL (e.g., "yoursite.com/return.cfm") over to the other site. When the user completes the transaction, the other site sends him or her back to that URL on your site. Once back on your site, your server doesn't recognize the user because CFID and CFTOKEN are missing. You can fix this by changing the return URL to include that person's session identifiers. Modify your code to create a return URL of "return.cfm?CFID=#Session. CFID#&CFTOKEN=#Session.CFTOKEN#" (all within a CFOUTPUT block, of course). This will put that user's session management values in the URL. When the user returns to your site using that URL, CF will look for these identifiers as cookies or as URL variables. The cookies still won't be there, but the correct values will be in the URL so session management can identify them.

Q: I have a question about your recommendation against copying shared-scope variables into the Request scope (CFDJ, Vol. 3, issue 12). At an Advanced CF course we were told that the duplicate function is very inefficient and resource-intensive, as is using the IIF function. I'm wondering if you've done any testing using the StructCopy function instead. I agree with you that copying information into the Request scope with every page load regardless of whether or not the page requires the data is a poor way to do things. However, why not have two templates, SharedToRequest.cfm and RequestTo-Shared.cfm? They'd contain the code needed to handle the task. You could then include them wherever shared-data access is required. This way you avoid needless memory access and are still able to reap the benefits of accessing variable information without locking.
A: I haven't done any testing on the StructCopy function, but I would avoid using it because it copies only the first level of the structure. Therefore, if you have a structure inside a structure, only the first level is copied. The nested structure is still a pointer.

I like your idea of having SharedToRequest.cfm and Request-ToShared.cfm cfincluded only where you need them. However, you'd still have some issues with the size of the data being copied and the number of people accessing these pages. The bottom line is: while it does take more time to place explicit cflocks around shared data requests, your applications will run faster than if you copy those pieces of data to the request scope before accessing them.

Please send your questions about ColdFusion (CFML, CF Server, or CF Studio) to AskCFDJ@sys-con.com. Visit our archive site at www.netsitedynamics.com/AskCFDJ.