Cart Library - possible problems

[eluser]got 2 doodle[/eluser]
To be totally fair the cart library is still under construction but since it is visible to the public we can start testing it and this will help the maturity of the library should Ellis Labs choose to include it in the up coming release.

I documented a bug here regarding the cart total.

I didn't put this in the bug report area because the library is still under development.

I have a couple of other comments and by starting this thread hopefully we can find a few problems, point them out to each other, perhaps Ellis labs will take note and then they can decide what to do with this info and everyone is good.

One possible problem is with the number_format() of the cart total.

Line 423:

Code:

return number_format($this->_cart_contents['cart_total'], 2);

This adds thousands separators, which could cause problems with amounts over $1,000.00 (not likely going to be my problem) ;-)

this might be a better idea

Code:

return number_format($this->_cart_contents['cart_total'], 2,'.','');

Now the total will be returned with no thousands separator and it will be available for further math functions.

The manual (again under construction) states that

To delete an item from your cart, pass an array containing the product ID and a quantity of zero to the $this->cart->update() function:

This is in fact not true, you have to pass the 'rowid' and a quantity of zero which brings me to my next point. This seems a bit awkward, it's ok if you are listing all of the items but not so easy if you know the product id, then you have to loop through the cart contents and find the 'rowid'.

I would rather have the library function as documented in the manual than have to pass the 'rowid'. I'm not an inventory wiz but I have managed inventory and it seems to me that an item id should include such things as the size of the shirt the color; and if you printed on the shirt that would now make the shirt an unique item. So rather than have options array, I would suggest a unique id is all that is needed. A large blue shirt has a different SKU than a large green shirt.

This last point is of course a matter of how you want to work, so one man's solution might be another man's curse.

Anyway, thanks Ellis Labs for this library, it is certainly workable as it stands, I have two projects right now that needed a cart library so for me the timing couldn't have been better.

Hopefully others will post useful suggestions and comments.
doodle

[eluser]obiron2[/eluser]
Your products table should have an internal unique productID that is used to X-ref related tables (stock locations, purchase orders, sales orders etc) This should be allocated internally by the system and does not need to be known by the user. You should also have at least 1 product code that is recognised as unique to that product by the system. It is likeley that you may have several codes that are unique to the product e.g.

My_ProductCode
Catalog_Product_number (the same product could have different IDs in different catalogs - helps with order source tracking and differential pricing)
Mfr_ProductCode (could be more than 1 manufacturer)
Barcode
OEM_PartNumber

In case you hadn't guessed, stock management systems are a pet topic of mine...

Obiron

[eluser]got 2 doodle[/eluser]

Your products table should have an internal unique productID

Yup, I'm good with that

Not to challenge but more to learn, do you agree with the current approach where we have to supply a 'rowid'?

Ultimately I just want to deal with that unique id that is assigned to the unique product. If for example the product is available in two stores, I want to deal with all of that logic before my customer places an order.

The item from built by Bob and the item built by Bill is another issue that should be completely different than what my customer needs to know, it's simply another layer on top of the complexity.

The customer says I want a large red shirt and clicks a button that add that unique item to the cart.

If the id for the shirt is a so-called "dumb number" like 2347888 or an intuitive product code like 'shrt_polo_lg_red', doesn't matter to my customer or the cart library. If I need to add extra logic to process the order, like find out who makes it what warehouse it's in etc. doesn't really come in to play with the simple cart paradigm.

So I as the programmer don't care about all the other stuff at this point in the process, I simply want to gather the items that the customer desires and I need to do this based on the uniqueness of the item at the customer selection level not at the supply chain level.

So just like a real shopping cart, I want a red shirt in there and I picked it from all the others in the store. If I change my mind I take the red shirt out and put in a green shirt. I as a customer don't care what order I put the shirt in. I as a programmer don't care where in the cart array the red shirt is I simply want to remove or change quantity of that item.

Changing the color of the shirt or the size is not an option once it is in my shopping cart, but I can take a shirt out and exchange it for another of a different size or color.

So to recap, do you agree with the current approach where we have to supply a 'rowid'?

Or does it seem sane to simply have to supply unique product ID, like the manual suggests?

And this is a serious question, because if you have a lot of stock management experience I am sure that lots of folks around here would value your opinion.

thanks,
doodle

[eluser]got 2 doodle[/eluser]
OK, so easy enough to get the rowid from your product ID. Personally I probably won't use the options array since it doesn't really make sense to me.

But, and this is huge! If you want to work that way you can! CodeIgnitor does it again with flexibility in mind.

to get the rowid I extended the Cart library

Code:

class MY_Cart extends CI_Cart {

/* function to return rowid */
    function row_id($id,$options=array())
    {
        if (count($options) > 0)
        {
            $rowid = md5($id.implode('', $options));
        }
        else
        {
            $rowid = md5($id);
        }        

        return $rowid;
    }


}

now I can just send the id to the controller that does the delete (id included in url)

Code:

echo anchor('lmf/product_delete/'.$product_id,'Delete');

and in the controller

Code:

/*******************************************************************************/    
    function product_delete()
/*******************************************************************************/    
    
    {  
$item = array(
               'rowid'      => $this->cart->row_id($this->uri->segment(3)),
               'qty'     => 0,
            );

$this->cart->update($item);    
redirect('/lmf/products', 'refresh');

    }

so all is good in the world ;-)

[eluser]Rick Ellis[/eluser]
Sorry about the incorrect information in the user guide. It's been updated.

[eluser]johnwbaxter[/eluser]
@got 2 doodle - Should you not typecast this $this->uri->segment(3)?

Code:

(int)$this->uri->segment(3)

I appreciate your product_id may not be an integer but i always make it one so that i can do the above. For some reason i really don't trust getting stuff from the url

[eluser]xwero[/eluser]
audiopleb i think it's better to check the content instead of typecasting. If somone deletes an item and sees it's still there after hitting the delete link without a warning they will trust your shopping basket less.

But you are right all input should be handled as untrusted.

[eluser]johnwbaxter[/eluser]
Yeah you're right, however, normal customers will never have a problem as the 3rd uri segment will always be an int, typecasting that would only inhibit nefarious types!

[eluser]xwero[/eluser]
It doesn't have to be a black hat operation. if other developers see a site uses get segments for actions and they think the action can be more user friendly, for instance make a ubiquity command for it, it's possible the input will be more times invalid than you have forseen, even for the actual shoppers.

I think the times when hackers where the only ones that payed attention to get and post actions are behind us and now developers see get and post actions as an api.

[eluser]johnwbaxter[/eluser]
Yes okay i see where you're coming from. I enjoyed you're use of "ubiquity command" by the way. Nice going!