Re: Carts & cookies
This WebDNA talk-list message is from 1999
It keeps the original formatting.
numero = 23245
interpreted = N
texte = >>>We need three newish cart tags, [&cart] [?cart] [input-cart] >>>these would all look for the presence of a cart in a cookie named cart >>>and hide themselves if their presence was not needed, and they would fill in >>>just like the above examples if a browser failed to send back a cart >>>value, but >>>WebCatalog would be programmed (possibly with a user selectable setting >>>to turn >>>this off?) to attempt to set a cookie with the current cart on any page >>>request >>>that didn't include the cart cookie. >> >>Sounds interesting, but this will create problems ... >> >>>If WebCatalog detects a cookie named cart, it uses that value >>>automatically for all cart tags that may be needed on that page. >> >>This is exactly where the problems will come in ... >> >>This technique would result in re-using a previously-used cart values for >>a new and completely different carts when the same user happens to return >>to the site to create a new order -- even if the previous order has >>already been completed. > > No. > > 1. Remove the cookie when purchase is done > 2. The should expire at the end of the browser session > > (on the other hand - there's other problems with cookies, so personally I > prefer the cart approach).Honestly, the fact that WebCatalog doesn't expire cart NUMBERS after some period of time is almost borderline unacceptable programming. Last month I had at least 4 people use the same cart number to check out days apart. What I mean by this is a guy comes to the site, and book marks some internal page. He then purchases something. I get the order, process it, and archive the order. Days later, he uses the bookmark (with the preused cart number, issued 14 days ago!) to make another purchase. The system allows this, as a file with that number doesn't exist in the order folder. I go to archive it, and low and behold, I overwrite the previous order with this new order. I have had to add programming to append a random number to the end of the order file name to make sure I don't overwrite my UNIQUE(?!?) cart based order numbers.I suppose I could leave the orders in the orders folder, then I could really PISS OFF the customer by popping up a cart has already been submitted message when he attempts to place his order, how's that for an idea?Anyway, WebCatalog should have a user selectable timeout where it sees a cart, and then it reissues a new cart number if the old cart number is too old (these cart numbers are based on a derivative of a time function, aren't they!)While we are here, why aren't carts Hex numbers, or even the whole alphabet + number (26 lower, 26 upper, 10 digits = 62 characters) to reduce the unwieldy length of these things??? Brian B. Burton BOFH - Department of Redundancy Department --------------------------------------------------------------- MMT Solutions - Specializing in Online Shopping Solutions 973-808-8644 http://www.safecommerce.comProtect your right to own and arm bears.
Associated Messages, from the most recent to the oldest:
>>>We need three newish cart tags, [&cart] [?cart] [input-cart] >>>these would all look for the presence of a cart in a cookie named cart >>>and hide themselves if their presence was not needed, and they would fill in >>>just like the above examples if a browser failed to send back a cart >>>value, but >>>WebCatalog would be programmed (possibly with a user selectable setting >>>to turn >>>this off?) to attempt to set a cookie with the current cart on any page >>>request >>>that didn't include the cart cookie. >> >>Sounds interesting, but this will create problems ... >> >>>If WebCatalog detects a cookie named cart, it uses that value >>>automatically for all cart tags that may be needed on that page. >> >>This is exactly where the problems will come in ... >> >>This technique would result in re-using a previously-used cart values for >>a new and completely different carts when the same user happens to return >>to the site to create a new order -- even if the previous order has >>already been completed. > > No. > > 1. Remove the cookie when purchase is done > 2. The should expire at the end of the browser session > > (on the other hand - there's other problems with cookies, so personally I > prefer the cart approach).Honestly, the fact that WebCatalog doesn't expire cart NUMBERS after some period of time is almost borderline unacceptable programming. Last month I had at least 4 people use the same cart number to check out days apart. What I mean by this is a guy comes to the site, and book marks some internal page. He then purchases something. I get the order, process it, and archive the order. Days later, he uses the bookmark (with the preused cart number, issued 14 days ago!) to make another purchase. The system allows this, as a file with that number doesn't exist in the order folder. I go to archive it, and low and behold, I overwrite the previous order with this new order. I have had to add programming to append a random number to the end of the
order file name to make sure I don't overwrite my UNIQUE(?!?) cart based order numbers.I suppose I could leave the orders in the orders folder, then I could really PISS OFF the customer by popping up a cart has already been submitted message when he attempts to place his order, how's that for an idea?Anyway, WebCatalog should have a user selectable timeout where it sees a cart, and then it reissues a new cart number if the old cart number is too old (these cart numbers are based on a derivative of a time function, aren't they!)While we are here, why aren't carts Hex numbers, or even the whole alphabet + number (26 lower, 26 upper, 10 digits = 62 characters) to reduce the unwieldy length of these things??? Brian B. Burton BOFH - Department of Redundancy Department --------------------------------------------------------------- MMT Solutions - Specializing in Online Shopping Solutions 973-808-8644 http://www.safecommerce.comProtect your right to own and arm bears.
Brian B. Burton
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Opinion: [input] should be called [output] ... (1997)
Webmerchant confirmation hooks? (1997)
Configuring E-mail (1997)
WebCommerce: Folder organization ? (1997)
WebCat2: Formulas.db question (1997)
Location of Browser Info.txt file (1997)
Bug Report, maybe (1997)
Frames and WebCat (1997)
[SearchString] problem with [search] context (1997)
Pull Down Search (2000)
international time (1997)
cart converting to scientific notation format (2001)
WC2.0 Memory Requirements (1997)
RE: Nested [SEARCH] and [REPLACE] problem. (1997)
Prevent multiple appends with Reload Button (1997)
PIXO support (1997)
Still having problems with Authen (1997)
TCPConnect misbehavin' for me. (2000)
WebMerchant when CC network is down (1998)
showcart is slow (1998)