And about Parameters, should we have the defaultValue property for ParameterDefinitions in Calculation module?
I'm trying to write a sample RuleAsCalculationWrapper and RuleAsCalculationWrapperEvaluator in logic module, the idea is RuleAsCalculationWrapper has a Rule property and when the RuleAsCalculationWrapperEvaluator.evaluate is called, we actually evaluate associated rule for the calculation wrapper and return the result after converting it to a Result in calculation module, probably we might have a ResultWrapper too. What do you think? Wyclif On Wed, Mar 14, 2012 at 10:53 PM, Wyclif Luyima <[email protected]> wrote: > 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]
