RE: ECommerce practices
I've always thougth writing to the db is a good idea to track abandoned carts.Sometimes, you can glean info on when and then why people are abandoning their carts. DRE -Original Message- From: Cutter (CF-Talk) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 6:10 PM To: CF-Talk Subject: ECommerce practices Just looking for other's insight. Can't think of a better group to ask... I'm setting up a custom ecomm area (current is a setup using the JASC component my boss implemented before I got here). What the big boss would like is something that wouldn't fit into the general templates you find all over, so I'm working from scratch on most of this. I'm trying to find what would be the best method for initially handling order details. Most of the items are apparel. The user would first select a category, then select a specific item/design from a thumbnail. Next they would be shown a larger image with the different colors it would be offered in. The user would select the color they want, taking them to the next screen where different size options would be available. The user would enter in the quantity of each size they may want. The next step would verify the item/design, basic product detail, color, sizes and quantities, and the price (showing price differences for oversized products as well). At this point it would then continue to the basics (name, addy, payment, etc.) My question is this. Every step of this process is some type of form. I could use hidden form fields to carry over all of the information from screen to screen, but this seems a little tedious, inelegant, and possibly somewhat insecure. What is suggested process in this type of situation? Should I set up some kind of struct var to handle the details? Would this best be handled within the session or client scopes? How does one best prevent race conditions? The end run is to write the details to a db once the order is processed, but I've seen what can happen when writing the details to a db from the get go and then having the user cancel the order or the payment is not approved (not my design, and it was ugly...) So, any suggestions are welcome and appreciated. TIA Cutter _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: ECommerce practices
On Thursday 25 Mar 2004 01:32 am, Peter Tilbrook wrote: CFTRANSACTION Quoting. -- Tom Chiverton Advanced ColdFusion Programmer Tel: +44(0)1749 834997 email: [EMAIL PROTECTED] BlueFinger Limited Underwood Business Park Wookey Hole Road, WELLS. BA5 1AF Tel: +44 (0)1749 834900 Fax: +44 (0)1749 834901 web: www.bluefinger.com Company Reg No: 4209395 Registered Office: 2 Temple Back East, Temple Quay, BRISTOL. BS1 6EG. *** This E-mail contains confidential information for the addressee only. If you are not the intended recipient, please notify us immediately. You should not use, disclose, distribute or copy this communication if received in error. No binding contract will result from this e-mail until such time as a written document is signed on behalf of the company. BlueFinger Limited cannot accept responsibility for the completeness or accuracy of this message as it has been transmitted over public networks.*** [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: ECommerce practices
To answer some of your questions My favorite way to pass variables from page to page is to create a struct of the form variables and then throw it in a wddx using the session scope. You could write a struct for each section and keep rolling it into wddx's. Then in the end roll them out and append the different structs into one which makes it easy to pass the variables as an argumentcollection in a CFC. -Original Message- From: Cutter (CF-Talk) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 7:10 PM To: CF-Talk Subject: ECommerce practices Just looking for other's insight. Can't think of a better group to ask... I'm setting up a custom ecomm area (current is a setup using the JASC component my boss implemented before I got here). What the big boss would like is something that wouldn't fit into the general templates you find all over, so I'm working from scratch on most of this. I'm trying to find what would be the best method for initially handling order details. Most of the items are apparel. The user would first select a category, then select a specific item/design from a thumbnail. Next they would be shown a larger image with the different colors it would be offered in. The user would select the color they want, taking them to the next screen where different size options would be available. The user would enter in the quantity of each size they may want. The next step would verify the item/design, basic product detail, color, sizes and quantities, and the price (showing price differences for oversized products as well). At this point it would then continue to the basics (name, addy, payment, etc.) My question is this. Every step of this process is some type of form. I could use hidden form fields to carry over all of the information from screen to screen, but this seems a little tedious, inelegant, and possibly somewhat insecure. What is suggested process in this type of situation? Should I set up some kind of struct var to handle the details? Would this best be handled within the session or client scopes? How does one best prevent race conditions? The end run is to write the details to a db once the order is processed, but I've seen what can happen when writing the details to a db from the get go and then having the user cancel the order or the payment is not approved (not my design, and it was ugly...) So, any suggestions are welcome and appreciated. TIA Cutter _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: ECommerce practices
If you are going to store it in the Session scope, then don't bother converting to WDDX.You only need to convert to WDDX when you need to store a complex variable (struct or array) as a string.If you want to store the FORM struct in the SESSION struct, just do this: cfset session.myform = form Now session.myform points to the same struct as form and you won't lose it. +---+ Bryan Love Database Analyst Macromedia Certified Professional Internet Application Developer TeleCommunication Systems [EMAIL PROTECTED] +---+ ...'If there must be trouble, let it be in my day, that my child may have peace'... - Thomas Paine, The American Crisis Let's Roll - Todd Beamer, Flight 93 -Original Message- From: Ryan Kime [mailto:[EMAIL PROTECTED] Sent: Thursday, March 25, 2004 6:52 AM To: CF-Talk Subject: RE: ECommerce practices To answer some of your questions My favorite way to pass variables from page to page is to create a struct of the form variables and then throw it in a wddx using the session scope. You could write a struct for each section and keep rolling it into wddx's. Then in the end roll them out and append the different structs into one which makes it easy to pass the variables as an argumentcollection in a CFC. -Original Message- From: Cutter (CF-Talk) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 7:10 PM To: CF-Talk Subject: ECommerce practices Just looking for other's insight. Can't think of a better group to ask... I'm setting up a custom ecomm area (current is a setup using the JASC component my boss implemented before I got here). What the big boss would like is something that wouldn't fit into the general templates you find all over, so I'm working from scratch on most of this. I'm trying to find what would be the best method for initially handling order details. Most of the items are apparel. The user would first select a category, then select a specific item/design from a thumbnail. Next they would be shown a larger image with the different colors it would be offered in. The user would select the color they want, taking them to the next screen where different size options would be available. The user would enter in the quantity of each size they may want. The next step would verify the item/design, basic product detail, color, sizes and quantities, and the price (showing price differences for oversized products as well). At this point it would then continue to the basics (name, addy, payment, etc.) My question is this. Every step of this process is some type of form. I could use hidden form fields to carry over all of the information from screen to screen, but this seems a little tedious, inelegant, and possibly somewhat insecure. What is suggested process in this type of situation? Should I set up some kind of struct var to handle the details? Would this best be handled within the session or client scopes? How does one best prevent race conditions? The end run is to write the details to a db once the order is processed, but I've seen what can happen when writing the details to a db from the get go and then having the user cancel the order or the payment is not approved (not my design, and it was ugly...) So, any suggestions are welcome and appreciated. TIA Cutter _ _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
ECommerce practices
Just looking for other's insight. Can't think of a better group to ask... I'm setting up a custom ecomm area (current is a setup using the JASC component my boss implemented before I got here). What the big boss would like is something that wouldn't fit into the general templates you find all over, so I'm working from scratch on most of this. I'm trying to find what would be the best method for initially handling order details. Most of the items are apparel. The user would first select a category, then select a specific item/design from a thumbnail. Next they would be shown a larger image with the different colors it would be offered in. The user would select the color they want, taking them to the next screen where different size options would be available. The user would enter in the quantity of each size they may want. The next step would verify the item/design, basic product detail, color, sizes and quantities, and the price (showing price differences for oversized products as well). At this point it would then continue to the basics (name, addy, payment, etc.) My question is this. Every step of this process is some type of form. I could use hidden form fields to carry over all of the information from screen to screen, but this seems a little tedious, inelegant, and possibly somewhat insecure. What is suggested process in this type of situation? Should I set up some kind of struct var to handle the details? Would this best be handled within the session or client scopes? How does one best prevent race conditions? The end run is to write the details to a db once the order is processed, but I've seen what can happen when writing the details to a db from the get go and then having the user cancel the order or the payment is not approved (not my design, and it was ugly...) So, any suggestions are welcome and appreciated. TIA Cutter [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: ECommerce practices
CFTRANSACTION -Original Message- From: Cutter (CF-Talk) [mailto:[EMAIL PROTECTED] Sent: Thursday, 25 March 2004 12:10 PM To: CF-Talk Subject: ECommerce practices Just looking for other's insight. Can't think of a better group to ask... I'm setting up a custom ecomm area (current is a setup using the JASC component my boss implemented before I got here). What the big boss would like is something that wouldn't fit into the general templates you find all over, so I'm working from scratch on most of this. I'm trying to find what would be the best method for initially handling order details. Most of the items are apparel. The user would first select a category, then select a specific item/design from a thumbnail. Next they would be shown a larger image with the different colors it would be offered in. The user would select the color they want, taking them to the next screen where different size options would be available. The user would enter in the quantity of each size they may want. The next step would verify the item/design, basic product detail, color, sizes and quantities, and the price (showing price differences for oversized products as well). At this point it would then continue to the basics (name, addy, payment, etc.) My question is this. Every step of this process is some type of form. I could use hidden form fields to carry over all of the information from screen to screen, but this seems a little tedious, inelegant, and possibly somewhat insecure. What is suggested process in this type of situation? Should I set up some kind of struct var to handle the details? Would this best be handled within the session or client scopes? How does one best prevent race conditions? The end run is to write the details to a db once the order is processed, but I've seen what can happen when writing the details to a db from the get go and then having the user cancel the order or the payment is not approved (not my design, and it was ugly...) So, any suggestions are welcome and appreciated. TIA Cutter [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
