Hi all,
I've been thinking about the ideas discussed in this thread, and I'd like to throw in my two cents.
At the moment, products are conceptually split between Product, ProductVariation and ProductOption. Being able to replace Product is great and that work should continue, but it only gets us part of the way to full customisation. We're still tied to Cartridge's options+variations paradigm, which is perfect for a lot of products but not everything.
I propose creating a well-defined interface cleanly separating the shop into two parts: the shopfront, and the shopping cart. This should be done with a couple of goals in mind.
Firstly, we should be able to add anything to the cart, by simply specifying an sku, description, price, quantity, image, etc - the things that are stored in CartItem now. Secondly, all of the code which provides the cart with info about its items - stock levels, working out discounts, upsell products, etc - should all be in one, easily-overrideable place. That could be a refactored Product model (bad idea), an entirely new interface class between carts and products, or on the cart itself, by providing an abstract CartBase and default implementation which can be replaced.
In my experience the requirements for the shopfront are much more variable than those for the cart. This arrangement would allow developers to swap out the online shopfront entirely if it doesn't fit the product they're selling, while still being able to rely on a well-tested and robust cart. It also lends neatly to integration with existing stock management systems.
Eventually, I'd like to see the two parts of the shop in two separate apps, with the shopfront app depending on the cart.
I'm keen to hear what everybody thinks about this. A shop with this functionality would be incredibly useful to me and I would be happy to put in the hours required to make it happen if people like the idea.
Alex