Non-normality (code repetition)

Hi there,

I'm making some modifications to opencart for a client. Part of this involves changing the cart and checkout output. I've noticed that the cart contents and totals are generated in catalog/controller/checkout/cart.php and twice in catalog/controller/checkout/confirm.php. It's essentially slightly different versions of the same code in three different places. I was wondering what the rational for doing it this way is, rather than calling a common cartContentsCompose() (or whatever) function.

Thanks

There's code repetition everywhere. As far as I know it's a design decision... it seems Daniel (the author) wants to keep the cart completely separate from the framework, while some people [citation needed ] think the current situation is a bit excessive and a compromise should be found between separation and convenience.

I dare say you could reduce opencart code size by more than half if you got rid of some of all that redundant code.

its obvious to see reasons behind it.


Products calculate tax seperately to the cart, 1 reason, you may want to charge tax but not display it on products.

Keeping them seperate makes it easier to remove one from the other without re writing the whole thing.

Thats just one example.

That does not mean anything. Its easy enough to pass a parameter and say when tax == true do something. I love opencart and my 9-5 job is currently making heavy customizations to it for the company I work for. However there is tons of unnecessary redundant code for reasons I don't know. There are no real instantiated objects. Everything is treated as it is static. There are no abstract classes or OO design patterns. Sometimes it runs very expensive queries. For example with categories it runs a seperate query for the category and one for each product and gets back lots of unnecessary information.

Its not perfect. I'm grateful for the developers giving their time to develop this for free. I just think these are some areas where it needs work.

drivenbyweb wrote:There are no abstract classes or OO design patterns.

If Daniel happens across this thread I can sense an OO programming lecture coming on.