Wyclif, I think that no matter what we use as the calculationName and configuration of the tokens will be pretty confusing, so our task is to come up with some sort of automatic registration mechanism. One option would be to let the calcuationName be "WEIGHT (KG)", which is simpler, but if we do that, then the user *also* has to make sure that the logic token for WEIGHT (KG) is set up. Whereas if we use the more complicated providerClassname + configuration, that's more complicated, but it sidesteps logic's buggy token registration mechanism.
Regarding converting results, I had been assuming that the evaluator would pre-emptively convert it to the relevant calculation result type, but the idea of using a LogicResultWrapper that lazily does conversion when you call the asType method seems pretty cool, and easier to implement. That said, if you do it that way, you won't be able to distinguish between single results and ListResults. E.g. you'll probably have to do LogicResultWrapper implements ListResult, even for logic rules that actually only return a single result. That seems wrong to me, but Burke may think it's fine. :-) -Darius On Wed, Mar 14, 2012 at 8:27 PM, Wyclif Luyima <[email protected]> wrote: > 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 >> >> >> > ------------------------------ > 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]
