Posted on 17/05/2021 10:01:48
Hi Allan
If that is what you need, go with it. But I would say that logically prices should be based on something you know before you make an order, anything else is a discount.
Stack overflow exception sounds like an endless loop, and that is what you would potentially get if you try to calculate a products price based on the cart, and the cart prices are based on the products price that depends on the order that depends on the product etc... You see the problem? A classic hen and the egg problem.
Using Common.Context.Cart can and will trigger price calculations in some situations since the cart can be loaded when a user comes back etc. It also handles a ton of other stuff like cart contexts, session, cookies, cart expiration rules etc.
My best bet is to get the cart directly like this: Services.Orders.GetById(cartId)and then somehow store the cart id in a place where you can get hold of it. But again, that cart id can be based on previous cart sessions coming from the user, a cookie or from session depending on your flow and your setup. And there is also cart context and cart expiration to take into consideration. So if you go with this approach, you can easily run into a scenario where the cart id you find with your own logic, does not match the one Dynamicweb would find.
You might be able to store the right cart id in i.e. a session using a pageloaded notification subscriber where you use common.context.cart, take the ID from that, store it in a session variable, and then in your price provider get that cart id to call the orderservice. Remember session null check. The order object you get from the service will have an orderlines collection that you can iterate. The order service will cache the object, so it will not get retrieved from database on each call.
Be careful of performance.
BR Nicolai
