As a convention in .NET, events whose names end with -ing (ie. Deleting vs. Deleted) occur before an action and are cancelable whereever possible. This allows you to prevent the actions from happening for whatever reason.
TeaCommerce does not follow this convention. It does have both types of events, occuring before and after an action, but the one occuring before is not cancelable - which means it is pretty much useless.
We had a case where we only want to allow certain users to delete orders. We thought this would be simple - just hook into the Order.Deleting event and cancel the action when required. Instead it proved impossible, since there is no way in the Deleting event to prevent deletion from occuring.
You are right about the convention and normally you can cancel an event. But the problem here being is that you could add order properties, add order lines, change payment country, change currency and the call order.Save(). Then if you rollback the country, then the currency change might also need to rollback because of business logic in Tea Commerce. So its pretty hard to have cancel mechanics when you only have one save method. Would be way easier if we changed the currency right away and also persisted it. But we don't :) Not something that we can easily rewrite as its a pretty huge change :)
I can totally understand what you say about the interaction with Order.Save(). That makes sense, given the architecture of TeaCommerce.
But what about the example I mentioned above? Deleting an order is a single action, and I see little reason that it should not be possible to cancel deletion from the Deleting event. And I'm sure there are other events where the same logic applies.
In the delete event it makes sense - you are right. Could you make an issue on GitHub describing what your would like. Then we have that for reference when we add it to the source.
Events happening before an action should be cancelable
As a convention in .NET, events whose names end with -ing (ie. Deleting vs. Deleted) occur before an action and are cancelable whereever possible. This allows you to prevent the actions from happening for whatever reason.
TeaCommerce does not follow this convention. It does have both types of events, occuring before and after an action, but the one occuring before is not cancelable - which means it is pretty much useless.
We had a case where we only want to allow certain users to delete orders. We thought this would be simple - just hook into the Order.Deleting event and cancel the action when required. Instead it proved impossible, since there is no way in the Deleting event to prevent deletion from occuring.
Hi Asbjørn
You are right about the convention and normally you can cancel an event. But the problem here being is that you could add order properties, add order lines, change payment country, change currency and the call order.Save(). Then if you rollback the country, then the currency change might also need to rollback because of business logic in Tea Commerce. So its pretty hard to have cancel mechanics when you only have one save method. Would be way easier if we changed the currency right away and also persisted it. But we don't :) Not something that we can easily rewrite as its a pretty huge change :)
Kind regards
Anders
Thanks for the reply.
I can totally understand what you say about the interaction with Order.Save(). That makes sense, given the architecture of TeaCommerce.
But what about the example I mentioned above? Deleting an order is a single action, and I see little reason that it should not be possible to cancel deletion from the Deleting event. And I'm sure there are other events where the same logic applies.
In the delete event it makes sense - you are right. Could you make an issue on GitHub describing what your would like. Then we have that for reference when we add it to the source.
https://github.com/TeaCommerce/Tea-Commerce-for-Umbraco
Kind regards
Anders
is working on a reply...