You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Jacques Le Roux (JIRA)" <ji...@apache.org> on 2018/05/01 09:33:00 UTC

[jira] [Commented] (OFBIZ-10370) Migrate promotion condition and action rule

    [ https://issues.apache.org/jira/browse/OFBIZ-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16459558#comment-16459558 ] 

Jacques Le Roux commented on OFBIZ-10370:
-----------------------------------------

Hi Nicolas,

I very like the idea. Initially I was reluctant to the use of Groovy for services, but now IDEs provide enough support to not be fearful

I did not test nor reviewed in details, but here are other points so far:

+                // TODO Auto-generated catch block
+                e.printStackTrace();

Rather use module = "ProductPromoActionServices.groovy" in debug log
"ProductPromoActionServices.groovy")

Thanks for ProductPromoCondTests ! :)

> Migrate promotion condition and action rule
> -------------------------------------------
>
>                 Key: OFBIZ-10370
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-10370
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: product
>    Affects Versions: Trunk
>            Reporter: Nicolas Malin
>            Assignee: Nicolas Malin
>            Priority: Major
>         Attachments: OFBIZ-10370.patch
>
>
> Currently promotion rule engine works with :
> * entities ProductPromoCond et ProductPromoAction
> * java linear function ProductPromoWorker.checkCondition() (ProductPromoWorker:910) and ProductPromoWorker.performAction (ProductPromoWorker:1423)
> * Enumeration list to indicate on java function what piece of code to activate the control or action
> The problem with this structure is when you want to create a new case of condition or action, you need to modify the framework code base.
> We propose an other way with convert the 2 big java leaner function to service representation with one service by case.
> To realize it we introduce a relation with CustomMethod :
>  ProductPromoRule --> ProductPromoCond -> CustomMethod
>  \-> ProductPromoAction -> CustomMethod
> Each functions's case are converted to service with a related CustomMethod.
> With this pattern now you can write your own condition rule and action rule on your plugin and link it on the promo engine
> When it's possible we associate a unit test to the service
> For backware compatibility current enumeration receive on enumCode the customMethodId to ensure that old data work fine with the new engine
> {code}
>  <CustomMethod customMethodId="PPC_PRODUCT_AMOUNT" customMethodTypeId="PRODUCT_PROMO_COND" customMethodName="productPromoCondProductAmount" description="Product amount"/>
>  <Enumeration enumId="PPIP_PRODUCT_AMOUNT" enumCode="PPC_PRODUCT_AMOUNT"/><!--link enumeration with customMethod for backware compatibility-->
> {code}
> {code}
>  //for backware compatibility resolve customMethodId from enumCode
>  GenericValue condEnum = EntityQuery.use(delegator).from("Enumeration").where("enumId", inputParamEnumId).cache().queryOne();
>  if (condEnum != null) {
>  customMethod = EntityQuery.use(delegator).from("CustomMethod").where("customMethodId", condEnum.get("enumCode")).cache().queryOne();
>  serviceName = customMethod.getString("customMethodName");
>  }
> {code}
> Related dev [discussion |https://lists.apache.org/thread.html/47730b60c9d1bab875e77577c2b4f16b99ede6dcdf68030f5cfc1203@%3Cdev.ofbiz.apache.org%3E]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)