Mike, I'm looking forward to discussing on the design call.
Dave, I like the way you're thinking, but I wonder if, since you're restricting the html forms to view-only mode, it might not be easier/more performant to do something new, based on groovy templates for this. (The code required is pretty simple, and can possibly be copied from 2.x.) Also, I think that the refactoring Mike is talking about doing will make this approach work a lot better. Currently, actually authoring all the logic rules you'll need will be annoying. -Darius On Mon, Nov 14, 2011 at 1:36 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > I am moving into logic. I am using it to determine the reference ranges > for certain lab tests, which are based primarily on age and sex but can > also be based on various demographic (e.g. ethnicity) or health status > (e.g. pregnancy) variables. I will be running multiple rules against a > single patient, but not many at a time. My main concern is that existing > high level features (logic expression definition, persistence and > evaluation) remain available. This is a very small piece of a very large > app and it is unlikely that people experienced with this aspect of OpenMRS > will be available. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Dave Thomas > Sent: Monday, November 14, 2011 4:14 PM > To: [email protected] > Subject: Re: [OPENMRS-DEV] The future of Logic > > Hi. My biggest push into using logic was during an early draft of the > mdrtb module version 2.0, in which I used it in a controller to create a > custom patient summary. The complaints about logic listed by Mike > basically reflect the experience. > > However, I've been thinking about how to create robust but generic > templates for patient summaries, for ANY clinical area quickly. And i > think one very powerful answer is htmlforms, restricted to 'view' > mode, with logic tokens being referenced through the htmlformentry tags. > If this was fast and robust, this would be EXTREMELY useful if I felt like > it wasn't going to be like going down the rabbit hole... > Is my impression about the state of things incorrect? > > d > > On 11/14/11, Michael Seaton <[email protected]> wrote: > > Hi all, > > > > Not much of a resounding response to this :), but I would like to move > > it forward. Can we discuss it during the Design Forum this week? > > > > Thanks, > > Mike > > > > > > On 11/09/2011 10:23 PM, Michael Seaton wrote: > >> Hi all, > >> > >> I wanted to pick up a thread on the future of Logic that we spent > >> some time discussing during the Developers Forum on October 27 > >> <https://wiki.openmrs.org/x/5oamAQ>. > >> > >> The overall consensus on the call was that /"Logic is too complicated. > >> We wish there were a simpler implementation, that were easier to > >> adapt to individual needs. We wish it were more rigorously tested, > >> including performance testing"/. > >> > >> *Anyone that cares about preserving Logic as it currently exists, or > >> wants to see it change in a specific way, please read further* > >> > >> Specific users of Logic have communicated the following needs: > >> > >> * Tammy and her team require more control over the current Logic > >> implementation, and better testing around it, so that future > >> upgrades do not cause serious bugs and performance degradation > >> * Win and Tammy need implementations of Logic that are optimized > >> for running lots of rules for individual patients at a time > >> * Mike needs an implementation of Logic that is optimized for > >> running a single rule for lots of patients at a time as well > >> * Mike wants to be able to choose to not use the existing Logic > >> implementation in favor of an implementation provided by the > >> Reporting module > >> > >> To accomplish this, the following high-level refactoring steps are > >> being considered: > >> > >> * Reduce and simplify the number of interfaces and interface > >> methods that Logic exposes in OpenMRS core > >> * De-couple the existing Logic Module in such a way that it is one > >> of many possible "Rule Providers" that can plug into this > >> lighter-weight core framework > >> * Remove, if possible and practical, the need to have a "required" > >> Logic module installed > >> > >> Specifically, we are considering an approach that would reduce the > >> core Logic interfaces to something like: > >> > >> interface LogicContext; > >> > >> interface Result; (classes DateResult, NumberResult, > >> ListResult...) > >> > >> interface Rule { > >> Set<RuleParameterInfo> getParameterInfo(); > >> Class<? extends Result> getReturnType(); > >> Result evaluate(Integer patientId, Map<String, Object> > >> parameters, LogicContext context); > >> } > >> > >> interface LogicService { > >> public Result evaluate(Rule rule, Patient patient, Map<String, > >> Object> parameters, LogicContext context); > >> public Map<Integer, Result> evaluate(Rule rule, Cohort cohort, > >> Map<String, Object> parameters, LogicContext context); > >> } > >> > >> I would like for this to spur the following potential activities: > >> > >> * Give anyone who has not yet been aware of these discussions, or > >> who does not agree with this approach, an opportunity to weigh > >> in and get involved in the process > >> * Make a plan to put this topic onto one or more future Design > >> Forum calls, in order to agree upon the revised design, make > >> tickets, and establish an owner for moving it forward. > >> * Publicize when this Design Forum will occur so that interested > >> parties can be involved as desired > >> > >> Thanks! > >> Mike > >> > >> > >> > >> --------------------------------------------------------------------- > >> --- > >> Click here to unsubscribe > >> <mailto:[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] > > > > _________________________________________ > > 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] > > _________________________________________ > > 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] > _________________________________________ 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]
