Intuitive User Interfaces for Report Designer

Owned by Burke Mamlin
Last updated: Jun 17, 2013 by David PalaciosVersion comment
3 min read

Intuitive User Interfaces for Report Designer

Primary mentor

@Mike Seaton

Backup mentor

@Lluis Martinez

Assigned to

@David Palacios

Abstract

The OpenMRS Reporting Module provides a powerful and flexible reporting framework for OpenMRS.  One element of this flexibility is that a single report may be output into a variety of different formats by configuring one or more Report Renderers.  Each of these types of Report Renderers has particular ways in which it can be configured - a simple CSV renderer, for example, may be configured with information as to whether the elements should be quoted, or whether a delimiter other than a comma should be used.  A renderer that delegates to a report engine like BIRT on the other hand, may require complex and detailed XML design files that control the exact layout and formatting of a report rendered to PDF.  Despite these differences, currently there is a single, generic user interface presented to users for configuring any renderer, which directly mirrors the object and data model of the object that is being configured - a Report Design.  The end user must either know how to configure a particular report renderer by looking at the code, or by looking at documentation on the wiki, which is frequently incomplete or outdated.  The objective of this project is to improve this, but adding custom pages for creating or editing each currently support Report Renderer, and by doing this in such a way that it is easy to create and plug in custom pages for new report renderer implementation that are created, either directly in the reporting module, or in dependent modules.

Project Champions

TBD

Objectives

  1. Modify the report definition editor and the report design editor so that the user first chooses a renderer type, which takes them into a custom editor for this type.  If no custom editor page is configured for the chosen type, the user should be taken to the current generic report design editor page.

  2. Create and plug in a custom UI for all non-configurable report renderers (IndicatorReportRenderer, SimpleHtmlReportRenderer, XlsReportRenderer, XmlReportRenderer).

  3. Create and plug in a custom UI for the DelimitedTextReportRenderer and it's subclasses (CsvReportRenderer and TsvReportRenderer)

  4. Create and plug in a custom UI for the TextTemplateRenderer (using as much from the patientsummary module as possible)

  5. Create and plug in a custom UI for the ExcelTemplateRenderer

  6. Create and plug in a custom UI for the CohortDetailReportRenderer

Extra Credit

As we build custom user interfaces for all of the existing report renderers, we are going to find that some of these renderers can be enhanced or merged together to provide more flexibility or usability.  Examples of areas that would benefit from slight refactoring before or while we create custom user interfaces:

  • Remove the CsvReportRenderer and the TsvReportRenderer, and convert the DelimitedTextReportRenderer so that it is no longer an abstract class, but rather a configurable bean.  This will allow users much more flexibility in how they output their delimited text output - to choose any delimiter they choose, to choose to quote or not quote the text, to change the line separator character, etc.  This task will also require writing a small migration script so that any existing ReportDesigns that use CsvReportRenderers or TsvReportRenderers will continue to work.  Alternatively, we could simply deprecate the CsvReportRenderer and TsvReportRenderer classes for now.

  • Merge the XlsReportRenderer and the ExcelTemplateRenderer into a single ExcelRenderer, which can either take in an Excel template to configure the output as in the existing ExcelTemplateRenderer, or if no template file is supplied, will simply  output the report into a stadard format as in the XlsReportRenderer.

  • Provide a place where we can plug the Birt report module in as a renderer:  https://tickets.openmrs.org/browse/REPORT-251

Resources

There are several outstanding tickets that will be addressed by this project, even if they do not explicitly ask for the above. The include: