RE: [mv] Refresh of cart re-orders item

["Warren Odom" <warren-odom@stenocall.com>]

******    message to minivend-users from "Warren Odom" <warren-odom@stenocall.com>     ******

> ******    message to minivend-users from ". c . o . r . y .  t . r . e . s
. e" <digital@frognet.net>     ******
>
> > > On Thu, 17 Aug 2000, Warren Odom wrote:
> > > > When you order an item, of course it displays the cart page.  If you
then
> > > > hit the browser Refresh button (say, because of some display
> > > > corruption-which is how I found this in the first place), you get a
> > > > duplicate order of that same item.
>
> When I first saw this post (this being the first post in the thread) I
went and
> installed a few of my templates to check to see if I was effected by this
> problem (I didn't remember hearing anything like this,) and I found that
in
> most of my setups I had avoided this by adding a "href=[area ord/user]" to
my
> [order...] tags.  I created the "ord/user" page to force people to either
a)
> create an account or b) log into an account.  that page used an if
statement to
> check for loggin in (and a refresh to [area ord/basket] if they are) and a
page
> for loggin in/signing up if they weren't.  These pages eventually linked
into
> the basket, and when that basket is refreshed, nothing extra is added to
the
> basket...

Yes, I saw the "&mv_order_item=<sku>" in the URL, and figured that's where
the extra item was coming from on a refresh.  It seems like enough of a
problem to me that it should be fixed.  I can just hear the customer
complaint now.  (Or, perhaps more likely, I hear nothing, as he decides the
system is too flaky to risk ordering at all!)

I also figured that an intermediate page, such as you describe, might fix
it.  But I also thought the nice Akopia people should be informed about
this-and might even come up with a better and/or easier fix.  After all,
having a glitch like this in their "showcase" demo is clearly suboptimal for
them.  It didn't take me too long to stumble on to it, either.  (And, since
then, I've tried the same thing with other shopping carts, and never had
this problem with any others.)

I just have this feeling that there ought to be a quick, easy, fix-but I'm
not intimate enough with MV/Interchange to know what it is.

> pps: you really can't knock the demo catalogs too much, they aren't
production
> systems, and I don't think anyone meant them to be (mike?)  I mean,
they're nice
> and everything, show off all the features in a very elegant way, but they
still
> aren't production systems.

Well, if not production, they're darn close.  People will expect to be able
to take the demo, customize the page design, plug in their product database
and go.  No one wants to rewrite stuff as complex as this (especially when
just getting started)-that's why you download it, so you don't have to
re-engineer it.

>******    message to minivend-users from Scott Benson <scott@rant.tzo.com>
******
>
>As Ryan Hertz pointed out earlier - the browser basically does another
>post of the values set in the page the order button was clicked from.

But of course normally when you refresh a page containing a form, the
browser warns you that this will entail a re-post.  People expect that
safeguard, which cannot be done in this case because there is no actual
form-it's just a button press.

>It just seems like there could be a way to do something similar to the
>[if ordered] tag to prevent it from being added to the cart  again...
>
>Scott

Yes, it does seem so.

           -- Warren

-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list