I would prefer Option B but i think assuming calculationName to be provider class name might be confusing, for some reason it is going to be very ticky to use the same getCalculation() method in a single CalculationProvider given that the rule providers expect varying values when getRule(String) is called i.e. it could be a token id, unique name or class name. Say for the RuleDefinitionRuleProvider's calculation provider equivalent, we can assume the calculationName is the name of the saved token but for Darius' snippet this won't work if the provider of the rule is ClassRuleProvider or is a data source provider
This line RuleProvider p = TokenRegistrationService.getRuleProvider(calculationName) seems strange, do we want to leak the notion of RuleProviders into the calculation module since TokenRegistration is in it. Wyclif On Wed, Mar 14, 2012 at 8:17 PM, Darius Jazayeri <[email protected]>wrote: > Hi Wyclif, > > This is an interesting question, and I'm not sure what the right approach > is. > > I don't think your options are phrased quite right--I think it should be: > > Option A: implement one single LogicCalculationProvider which is capable > of fetching all logic rules. > If we went this route, I'd suggest: > > - calculation's TokenRegistration.ruleName would be the classname of > the logic RuleProvider > - calculation's TokenRegistration.configuration would be directly the > configuration string for the logic RuleProvider > - we would completely ignore tokens registered in the logic module. It > would be perfectly fine for the same underlying rule to be exposed as the > calculation token "Chica A12", whereas it might be "A12" in logic, or not > even have a token registered in logic. > > An alternate single provider approach would be to only expose as > Calculations, rules that have tokens registered in logic. E.g. the > calculation's TokenRegistration with ruleName="WEIGHT (KG)" and > configuration=null would ultimately end up calling LogicService's > eval("WEIGHT (KG)"). Personally I like this approach less, but I haven't > thought it through much. > > Option B: one CalculationProvider per RuleProvider in logic. If we're > doing this: > > - expose *all* the logic RuleProviders (including the data source > ones) as CalculationProviders > - but you don't need to care about how the data sources work. Just get > all of them, and delegate to their getRule(String config) method. > > And actually, having written this email, I now favor Option A (my first > variant). > > Off the top of my head the code would look something like this: > > class LogicCalculationProvider implements CalculationProvider { > public Calculation getCalculation(String calculationName, String > configuration) { > // treat calculationName as the fully-qualified classname of the logic > RuleProvider > RuleProvider p = > TokenRegistrationService.getRuleProvider(calculationName); // need to write > this method > if (p == null) throw new Exception(); > // pass configuration straight through to the logic RuleProvider > Rule rule = p.getRule(configuration); > return new RuleAsCalculationWrapper(rule); > } > } > > The bulk of the code would actually be around converting logic's results > to calculation's results. > > Also, looking at this, I think we should add a *checked* exception to > CalculationProvider.getCalculation, like > InvalidCalculationConfigurationException or something. Given that we're > counting on two String being interpreted correctly, I'd much rather have a > compile-time exception than a runtime one. > > -Darius > > On Wed, Mar 14, 2012 at 2:20 PM, Wyclif Luyima <[email protected]> wrote: > >> Hello, >> >> In the effort of refactoring logic to expose itself in a way based on the >> calculation module i'm trying to figure out how to handle the >> LogicCalculationProvider(s) and i need your views on this. The current >> logic module has 2 main rule providers, the ClassRuleProvider and >> RuleDefinitionRuleProvider(I'm trying to ignore the DataSourceRuleProvider >> since i'm not yet sure how this is going to be incorporated). 2 questions >> come to my mind, >> >> 1. Should we have 2 separate LogicCalculationProviders equivalents >> for these? >> 2. If yes, RuleDefinitionRuleProvider looks up Rules stored as tokens >> in the database which is the equivalent of TokenRegistrations in the >> calculation module, does it mean that the CalculationProvider equivalent >> for it should instead go through the TokenRegistrationService and the >> equivalent for ClassRuleProvider goes through the >> ClasspathCalculationProvider? >> 3. If no, What are your suggestions? >> >> >> Wyclif >> >> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
