I would simply create a component called Cart and add a read() method to
just pull the products. Something like this:
class CartComponent extends Object {
var $components = array('Session');
function read() {
$Product = ClassRegistry::init('Product');
$productsInCart = $this->Session->read('Cart');
$cart = array();
foreach ($productsInCart as $product) {
$cart[] = $Product->read(null, $product);
}
return $cart;
}
function save($id) {
$productsInCart = $this->Session->read('Cart');
$productsInCart[] = $id;
return $this->Session->save('Cart', $productsInCart);
}
}
Then you access it from the controller and you're good to go. Technically
it's not MVC since the Cart should be a model, but do you really want to
write a datasource to pull/save to the Session just for something simple
like this? I mean, since there will only ever be *one* cart record (from
the eyes of the user) it doesn't seem to make sense to go to all the
trouble. Breaking MVC patterns is okay every once in a while :) This
component would be easily testable and separate from your controller.
On Tuesday, February 28, 2012 1:06:27 PM UTC-8, Christian wrote:
>
> Hi,
>
> I'm currently trying to create a shopping cart solution with cake 1.3.
> In the current design, only the product id of a chosen product will be
> saved in the session, each time the customer lists the cart items, all
> information needs to be read out of the database.
> My idea was to create a seperated model (no relation to any table)
> where all cart calculations can happen in, which can then be used in
> several controllers. However, this would mean that this cart class
> would need to use several other product related models (product
> details, taxes, countrydetails, etc.), which is not easily supported
> by cake, since it breaks the MVC model.
> The workaround would be to implement the logic in a controller where I
> can easily access all models, however, this breaks two other basics,
> once the "fat model skinny controller" rule and on the other hand the
> code is not easily reusable for other purposes.
>
> My question is now how where to implement the cart functionality (e.g.
> summary price, discount, taxes calculation, etc.) without breaking MVC
> but with sticking to "fat model skinny controller" and the re-
> usability of my code.
>
> Thanks,
> Christian
On Tuesday, February 28, 2012 1:06:27 PM UTC-8, Christian wrote:
>
> Hi,
>
> I'm currently trying to create a shopping cart solution with cake 1.3.
> In the current design, only the product id of a chosen product will be
> saved in the session, each time the customer lists the cart items, all
> information needs to be read out of the database.
> My idea was to create a seperated model (no relation to any table)
> where all cart calculations can happen in, which can then be used in
> several controllers. However, this would mean that this cart class
> would need to use several other product related models (product
> details, taxes, countrydetails, etc.), which is not easily supported
> by cake, since it breaks the MVC model.
> The workaround would be to implement the logic in a controller where I
> can easily access all models, however, this breaks two other basics,
> once the "fat model skinny controller" rule and on the other hand the
> code is not easily reusable for other purposes.
>
> My question is now how where to implement the cart functionality (e.g.
> summary price, discount, taxes calculation, etc.) without breaking MVC
> but with sticking to "fat model skinny controller" and the re-
> usability of my code.
>
> Thanks,
> Christian
On Tuesday, February 28, 2012 1:06:27 PM UTC-8, Christian wrote:
>
> Hi,
>
> I'm currently trying to create a shopping cart solution with cake 1.3.
> In the current design, only the product id of a chosen product will be
> saved in the session, each time the customer lists the cart items, all
> information needs to be read out of the database.
> My idea was to create a seperated model (no relation to any table)
> where all cart calculations can happen in, which can then be used in
> several controllers. However, this would mean that this cart class
> would need to use several other product related models (product
> details, taxes, countrydetails, etc.), which is not easily supported
> by cake, since it breaks the MVC model.
> The workaround would be to implement the logic in a controller where I
> can easily access all models, however, this breaks two other basics,
> once the "fat model skinny controller" rule and on the other hand the
> code is not easily reusable for other purposes.
>
> My question is now how where to implement the cart functionality (e.g.
> summary price, discount, taxes calculation, etc.) without breaking MVC
> but with sticking to "fat model skinny controller" and the re-
> usability of my code.
>
> Thanks,
> Christian
--
Our newest site for the community: CakePHP Video Tutorials
http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others
with their CakePHP related questions.
To unsubscribe from this group, send email to
[email protected] For more options, visit this group at
http://groups.google.com/group/cake-php
