|
[ 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) |
| Free forum by Nabble | Edit this page |
