[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Cookies at XML Europe 2004 -- Call for Particip ation
At 1:47 PM -0500 1/6/04, Amelia A Lewis wrote: >On Tue, Jan 06, 2004 at 06:41:52PM +0100, Nicolas Toper wrote: >>Eyes rolling for the Javascript solution :=) >> >>You could also but some variables in post to describe the cart... It's a pain >>but could be done > >Not really. I have a particular website in mind. That site uses >well-formed HTML (not declared as xhtml, but as close as I can get without >the customer going ballistic) and CSS. CSS means that I don't have the pain >of frames, but can have omnipresent navigation and relatively sophisticated >layout without tables. Goal of all this is to make it maintainable, *and* >to make it very, very easy for a customer to browse. > >In order to make it easy, I *also* need to use GET as often as possible, so >that the customer can freely hit the Back button without getting the >irritating "oh, you wanna buy another one, do you?" dialog box. The few >places where I've got POST (because the action isn't idempotent), I also >provide a special button (php constructed) that performs an action >equivalent to back (go back to the middle of the list that you were just >looking at). Amazon, btw, seems to add to the cart without using POST, >which always struck me rather oddly. > This is a very tricky case. I've had to think about it for a while, and I think it's doable. The key is that you give every shopper a cart, almost no matter what. The first time they hit your site at http://www.store.com/ you immediately redirect them to http://www.store.com/cartid/ where cartid is randomly selected identifier string. Internal URLs should all be relative off of the /cartid/ base. This will make it easier to keep track of the cartid without having to do lots of dynamic rewriting of pages. Your database keeps track of what they've purchased in the usual way by matching cartid to a list of items they've added to their basket. Once they do log in to purchase, you can either assign cartid to their user name permanently or just swap the baskets on them. I'm not perfectly happy with this, and I won't be surprised if you poke holes in it. The biggest problem I see is that I'd like the main page not to redirect. Possibly, you could make the main page not redirect, and have all its URLs rewritten to point to the randomly chosen cartid. Then use /cartid/ with relative URLs from that point forward. There may be a cleaner solution I haven't thought of yet. I do have one that might satisfy you, though it doesn't quite meet your criteria. What if registration were less onerous than usual? In particular what if the login page accepted non-registered usernames and passwords, and immediately registered them? i.e. login equals registration? There should be a cleaner solution though. I'm pretty sure the shopping cart should be a resource and that it should have a URI of its own. And I agree that you shouldn't have to POST into the shopping cart. I'd like to think that this could be done without rewriting every URL, but the problem I keep bumping up against is that there are separate resources for the general public pages and the shopping cart, and HTTP normally doesn't want to see more than one resource at once. I need to give it some more thought. -- Elliotte Rusty Harold elharo@m... Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|