Closed keberle closed 5 years ago
As you right noticed the logic with conditions has been seriously reworked. I just have been finished work on it and made this commit https://github.com/VirtoCommerce/vc-platform-core/commit/bae4ebad412710b24af3f924fb102bcd0df3e8dd and now it looks like as final version.
According to the latest changes for adding the new conditions in an expression tree you have to do follow things: Define a new derived prototype for extendable expression tree
public class MyPromotionConditionAndRewardTreePrototype : PromotionConditionAndRewardTreePrototype
public MyPromotionConditionAndRewardTreePrototype()
{
AvailableChildren.OfType<BlockCustomerCondition>()
.FirstOrDefault()
.WithAvailConditions(new MyNewCondition());
}
}
and override the original tree prototype with a new one in the Module.cs
void Initialize(IServiceCollection serviceCollection)
{
...
AbstractTypeFactory<PromotionConditionAndRewardTreePrototype>.OverrideType<PromotionConditionAndRewardTreePrototype, MyPromotionConditionAndRewardTreePrototype>();
...
}
We had been using the IMarketingExtensionManager and IPricingExtensionManager to replace the Virto conditions with our own in our module extensions. Now it looks like that mechanism has changed. What is the correct way to do it now?
Using Pricing as an example:
Would I get the TypeInfo from the typefactory and just replace the SetupAction with my own or would it be better to override the TypeRegistration of TypeInfo and replace it with another one so that the setup action resolved to mine instead?
I understand this is Beta and subject to change but I'd like to fix my module eextension in a way that is less likely to break going forward.