Re: patch for slipping modification index

[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'

Then delete item 0 and the state evolves to:

$cart->[0]->{foo} = 'B' != $::Values->{foo0} = 'X'
$cart->[1] = undef         $::Values->{foo1} = 'B'

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.

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.


> -- 
> Mike Heins                          http://www.minivend.com/  ___

--
john edstrom | edstrom@teleport.com