[Project] shopX 2.1

Quote from: sottwell at Mar 31, 2006, 12:02 AM

It’s something I just need to do. I know exactly how I intend to go about it.

Susan, I could help you with any stupid work such as html-coding the form or something else.
Hey, gues! Who can help Susan?!

I’ll help test. I’ll look at simple stuff like HTML and CSS too, if that helps.

No, it’s just that I have to take the time to concentrate and get my head back into the code. Right now I’ve got a lot of different things coming at me from a lot of different directions, and I don’t multitask well.

Ok. For the rest of this week, I work on this. No more home page modifications for my partner, the newsletter registration feature for the local php user’s group website will have to wait. And no Ajax until the basic functionality of this is finished, although Ajax is sure a lot more fun!

Great Susan!

Quote from: sottwell at Apr 04, 2006, 11:09 AM

Ok. For the rest of this week, I work on this.

I’ve run into a nasty problem that I don’t know how to solve. Under certain circumstances, if the user clicks the "back" button on his browser, or refreshes the page, the plugin repeats the latest form submission (such as adding items to the cart if returning to the shopping catalog), adding the items again. I need to be able to tell the plugin to ignore the POST if it’s a page refresh or the back button. Do any of you smart people have a suggestion or a link to information on how to deal with this? I’m researching the issue, but finding far more questions than answers!

Hi Susan,

This page relates to ASP, but thought that some of the ideas might still be relevant.

http://aspalliance.com/687

I had to deal with this a few times, and IIRC, I did it by associating a unique string based on the time&date (plus optionally the user’s ip) with each transaction. You need a field in the database to store this with each added item. Just check for existing identifiers, and reject the ones that exist. It means a trip to the server: these days, a bit of AJAXness would be helpful.

your change on a dollar: 0.98.

I’ve already examined and considered most of these methods. The first problem is that the data are not being stored in a database as this point, they are maintained in the SESSION because the user may or may not be logged in at this point; in fact for some applications the shop master may not want users to have to be logged in. For example, PayPal has its own forms that can be linked to as a checkout option, so the online shop does not need to handle user processing at all, merely pass the items and costs. The shop’s records are not created until a successful PayPal transaction is returned, and these may consist of email notification that is input into a local database.

The second reason is that a customer may wish to repeat the order intentionally. His cart will show how many of a given item he has ordered, the item’s individual cost, and a running subtotal. If the customer decides to order another of a given item, then the quantity of that item is incremented and the running total recalculated.

This sounds like the hidden field and a timestamp, with the timestamp being stored in the session for later comparison might be made to work. Since the data are only stored in the session to begin with, losing a session will cause the customer to lose his cart completely anyway. I willl have to ponder the logic of this, though, I’m kind of hazy on exactly how it would work. Looks like good ol’ trial-and-error time again!

Quote from: sottwell at Apr 06, 2006, 02:13 AM

I’ve already examined and considered most of these methods. The first problem is that the data are not being stored in a database as this point, they are maintained in the SESSION because the user may or may not be logged in at this point; in fact for some applications the shop master may not want users to have to be logged in. For example, PayPal has its own forms that can be linked to as a checkout option, so the online shop does not need to handle user processing at all, merely pass the items and costs. The shop’s records are not created until a successful PayPal transaction is returned, and these may consist of email notification that is input into a local database.

in principle, this is no different from logging, and doesn’t require a login by the user: why not have a separate table, or even a text file, or a flat berkely db separate from the main db that simply records the on-the -fly generated timestamp&ip ids, separate from any cart issues. The records can expire after a certain time, so the maximum size of the table/file would be as many cart transactions take place in the expiry period, probably a small number, ie avg 10 users, x 1 transaction a minute x 24 hour expiry = 14,400 lines/records.

The second reason is that a customer may wish to repeat the order intentionally. His cart will show how many of a given item he has ordered, the item’s individual cost, and a running subtotal. If the customer decides to order another of a given item, then the quantity of that item is incremented and the running total recalculated.

Sure, but since the detection would only happen when someone backs into something that has already been processed, do you think that anyone is going to repeat orders by using the back button**? What’s being detected is a duplicate timestamp & ip, nothing to do with the contents of the order. If a repeated identifier is found, then a mechanism like a popup or a div that you make visible could ask if that is the user’s intended action.

(** to clarify: I understand that someone might back up to a previous page to increase an order, or reduce it or whatever. By putting a confirmation page after the user says ’add to cart’, with a ’continue shopping’ button, it will usually be that page that they hit first, and that’s where the action you are flagging takes place. If they use the Back menu to go directly to where they can specify the type and quantity, then there is no problem, no?)