Hi. Here's a more thought-out proposal for how i'd like to be able to
build Indicators from generic DataSets. (mostly for Mike)
update SqlDataSetDefinition
add setPatientIdColumnName (this is hard-coded into
SqlDataSetEvaluator right now, and should be more flexible)
update SimpleDataSetMetaData
add DataSetColumn getDataSetColumn(int colIndex)
add DataSetColumn getDataSetColumn(String colName)
update DataSetColumn
add List<Object> getColumnValues();
add int getColumnIndexInDataSet();
create TabularDataSet extends SimpleDataSet
DataSetColumn getColumn(String columnName)
DataSetColumn getColumn(int colIndex)
(note: MapDataSet extends SimpleDataSet, so i don't think we'd want
to just expand SimpleDataSet itself?)
(note: different classname?)
update SQLDataSetEvaluator
should return a TabularDataSet
create interface DataSetAggregator
public String getName();
public Number compute(List<Object> values); ( the 'values'
argument would be from
TabularDataSet.getColumn(colName).getColumnValues() or rowValues())
public void setArguments(Object[] args);
create a bunch of DataSetAggregators -- these should expect Objects,
not Numbers: if numeric, we can pass through to existing aggregators
if appropriate. But then it would be good to start building things
like CountGreaterThan, CountGreaterThanOrEqualTo, CountLessThan,
CountLessThanOrEqualTo, PercentAbove, PercentBelow,
PercentBelowInclusive, PercentAboveInclusive, which can take
argument(s); and for Strings: CountEquals, CountNotEquals.
(NOTE: these could accept Parameters someday...)
update AggregationUtil
add public static Number aggregate(Collection<Object> values,
Class<? extends DataSetAggregator> aggregator)
create DataSetColumnIndicator
setDataSetDefinition() (should we create a new DataSetDefinition
interface that signals that this DataSet is a valid source for a
DataSetColumnIndicator?)
setAggregator() (optional if query returns a single value)
setBaseCohort() (optional)
create:
@Handler(supports={DataSetColumnIndicator.class})
DataSetColumnIndicatorEvaluator implements IndicatorEvaluator
methods: evaluate(): handles aggregations returns a Number
for now. Handles intersection with optional BaseCohort even though
this intersection can also happen in SqlDataSetDefinitionEvaluator?
create:
DataSetColumnIndicatorResult implements IndicatorResult
properties: DataSetColumnIndicator
EvaluationContext
Darius' description of SQLIndicator (which could extend
DataSetColumnIndicator and use all the underlying machinery from this
proposal...) applied here also:
* IndicatorDataSetDefinition (based on
CohortIndicatorDataSetDefinition or
CohortIndicatorAndDimensionDataSetDefinition). The simplest way would
be to just have a @ConfigurationProperty List<Mapped<Indicator>>
property. More sophisticated would be to add a baseCohort property,
and allow each column to optionally have dimension options specified
too.
* IndicatorDataSetDefinitionEvaluator (just iterates through each
indicator in the data set definition and delegates to the evaluator
for it).
* ReportRenderer capable of handling reports with an
IndicatorDataSetDefinition. (Alternately, just use the
ExcelTemplateRenderer.)
Also, i think persistence in the serialized_object table for saving
all this stuff should just work...
I've also not considered the UI here. See Darius' SqlIndicator
proposal for how to do this.
thanks, dave
_________________________________________
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]
