[
Lists Home |
Date Index |
Thread Index
]
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@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
|
