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]
