Re: patch for slipping modification index

[mikeh@minivend.com]

Quoting edstrom@teleport.com (edstrom@teleport.com):
> 
> mikeh@minivend.com
> >
> ...
> > Hmm -- this might make some sense in a different context. But as it is,
> > I won't be adding it.
> >
> > Normally, if you are using "NewTags Yes" and do any modifications to the
> > cart _before_ you use the [item-list] containing [modifier-name ...],
> > then there should be no trouble.
> >
> > The best place to do cart modifications is the Autoload macro
> > or an mv_click.
> >
> > For all users, all the time:
> >
> >       Autoload        [perl arg=carts] CODE [/perl]
> >
> >       (using a UserTag is better for speed here)
> ...
> 
> Thanks.  I don't have time right now but I'll look into the suggestions in
> a few days when I have some time.  I confess though that I don't see how
> mv_click routines would work at this moment.  I wonder if maybe I didn't
> explain the problem clearly enough.  The problem isn't with
> $item->{attribute} as such, its in the loss of synchronization between
> $item->{attribute} and $::Values->{attributeN}.  
> 
> When an item is deleted $item->{attibute} follows the item properly in the
> array.  As you say, there is no problem with the cart update per se.
> However, form elements such as <SELECT> and CHECKBOXes seem to be set from
> $::Values->{attributeN} when [selected [modifier-name foo] foovalue] is
> used to maintain the state of the form element. As far as I could tell,
> $::Values->{*} don't update following item deletion. The problem I was
> seeing looked like this:
> 
> at some point the minivend state looks like this with everything in sync:
> 
> $cart->[0]->{foo} = $::Values->{foo0} = 'X'
> $cart->[1]->{foo} = $::Values->{foo1} = 'B'

Aha. 
> 
> Then delete item 0 and the state evolves to:
> 
> $cart->[0]->{foo} = 'B' != $::Values->{foo0} = 'X'
> $cart->[1] = undef         $::Values->{foo1} = 'B'

But what are you using $::Values->{foo0} for anyway? It is totally
meaningless except as an indication of what the original form was. At one
point I was deleting it after update, but it became convenient to have
it there as a record of the form. MiniVend never uses that value.

> 
> so that although cart->[0]->{foo} had the correct old value, the form
> element set from the attribute, 
> 
>   eg via <OPTION  [selected [modifier-name foo] [loop-code]]...>
> 
> would set with the wrong value for the foo attibute.  The next update will
> then move the unintended values into the item foo attribute from the
> erroneously selected form elements.

Hmm. I toss the cart (deleting items) AFTER the attribute
update is done.

> 
> Maybe I'm overanalyzing it or looking at it the wrong way around, but I
> don't see how to keep an item attribute and a value attribute synchronized
> except with a mechanism that knows about prior state at the time an item
> is appended to or removed from the array.  My impression is that items
> are deleted or appended before control passes to ord/basket. I guess I
> don't know how to control exactly when a chunk of code gets executed in
> the general flow.

The attributes are updated before you get to ord/basket, so that shouldn't
be a problem if you put it on the page.

This will require some more thought, I think. But there is no easy way to
handle all contingencies, at least one that comes directly to mind. The
best thing to do is know what you are doing to the cart and update the
CGI values yourself.

-- 
Mike Heins                          http://www.minivend.com/  ___ 
                                    Internet Robotics        |_ _|____
                                    131 Willow Lane, Floor 2  | ||  _ \
It's a little-known fact            Oxford, OH  45056         | || |_) |
that the Y1K problem caused         <mikeh@minivend.com>     |___|  _ <
the Dark Ages. -- unknown           513.523.7621 FAX 7501        |_| \_\