[ic] [item-subtotal] in array lists

Karnei Gozman kgozman at detroitweb.net
Wed Jun 3 14:09:52 UTC 2009


Mike, you are such a rebel, never give up on your sequential replying  
format

-K

On Jun 3, 2009, at 10:06 AM, Mike Heins wrote:

> Quoting Stefan Hornburg (Racke) (racke at linuxia.de):
>> Mike Heins wrote:
>>> Quoting Stefan Hornburg (Racke) (racke at linuxia.de):
>>>> Mike Heins wrote:
>>>>> Quoting Stefan Hornburg (Racke) (racke at linuxia.de):
>>>>>> Hello,
>>>>>>
>>>>>> Is there a reason that [item-subtotal] doesn't work in array  
>>>>>> lists like
>>>>>>
>>>>>> [query sql="select sku,quantity from cart_products where cart =  
>>>>>> 2009" list=1]
>>>>>> ...
>>>>>> [/query]
>>>>>>
>>>>>> It appears to be an omission which should be fixed in  
>>>>>> Interpolate.pm.
>>>>>>
>>>>> Why? There is no cart item to subtotal.
>>>> Table cart_products has sku and quantity as the inline shopping  
>>>> cart.
>>>> So there are cart items to subtotal.
>>>>
>>>> Purpose:
>>>>
>>>> I don't want to store saved carts (and wishlists) into Perl hashes
>>>> inside database fields.
>>>>
>>>>> Now if you decided to allow
>>>>> cart items to be arrays as well as hashes,
>>>>>
>>>>> I think it would be as useful to have [item-math quantity *  
>>>>> subtotal].
>>>>>
>>>> IMHO all lists should behave pretty much the same. These  
>>>> undocumented
>>>> exceptions aren't any good.
>>>
>>> They aren't undocumented. But even if they were, the work that  
>>> someone
>>> should do is to bring hash and array lists together completely.  
>>> And I
>>> don't quite see how to do that. 8-)
>>
>> OK, but you agree it would be a good thing ?
>
> I always think those things are good *if they don't detract from  
> speed*.
> When it just means loading more and more and more on top, I am against
> them.
>
>>
>>>
>>> But it occurs to me that it would not be too difficult to provide
>>> this exception routine (pseudo-code)
>>>
>>> 	s{\[item-(\w+)\s*(.*?)\]}{extra_routines($1, $2)}g;
>>>
>>
>> That would make the whole list business a lot more flexible.
>>
>
> And faster. We could handle the most common cases in separate runs,
> and less common ones elsewhere. We do have ordering to think of, but
> if it is only new things it shouldn't be a problem.
>
> -- 
> Mike Heins
> Perusion -- Expert Interchange Consulting    http://www.perusion.com/
> phone +1.765.328.4479  <mike at perusion.com>
>
> Software axiom: Lack of speed kills.
>
> _______________________________________________
> interchange-users mailing list
> interchange-users at icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users




More information about the interchange-users mailing list