Adding Web Renderer to Reporting UI

Hi @mseaton & @darius ,

We have created a number of reports for iSantéPlus and would like to make it easy to view the reports when they are run. The reporting module has a web renderer feature that isn’t currently supported by reporting UI. I even see that there was code commented out for this feature.

Is the web renderer an appropriate thing to implement? If not, do you have thoughts on a path forward for allowing users to view HTML forms when they are run? Effectively, we would want to be able to “view” an HTML file if that’s the rendered type instead of downloading the file to our computer first and opening the file.

Thanks, Craig

FYI @jamesfeshner, @nathaelf


Great question, and any type of additional capability that you could give the platform is always well appreciated especially within an open source context. I have been playing around with my own open MRI’s environment especially the reporting solution and have been pondering/frustrated with how the design could be made better. I think a number of key questions should be asked before developing any form of reporting capability. I understand a lot of this is probably more information than you need to answer your question that it stuff that I’ve been thinking about for a while. So here goes;

  1. What types of questions will each defined user group be asking of your reporting tool? - How will your users benefit from reporting ? Think about it. If you can clearly articulate the need, you will also be able to decipher the type of questions they’re likely to ask in order to attain that benefit.
  2. How much time can your defined reporting user groups spend searching for and analysing data? - Most will be data consumers; not information developers.
  3. What specific job function does each user and user group perform? - Understanding the specific job function of each defined user group will enable you to understand how reporting can be most effectively harnessed to support their organizational roles, and further, what type of reporting content will be most applicable and useful.
  4. What are the technical capabilities of each defined user group? - The majority of the audience, and hence most of your reporting users and user groups, are likely to be business-users of a non-technical background – task workers who consume (rather than create) reports to enhance performance and make good decisions.
  5. How often does each defined user group need to access reporting content to effectively support role-based decision-making? - Establishing the frequency with which different user groups require access to reporting content will affect: The type of reports received / delivered … The timeliness of the data required.

Anyway I’m not quite sure that helps very much but I hope that it helps you thinking about how to develop and implement your additional capability to the reporting UI?

@craigappl, I haven’t looked recently, but would suspect that this should be relatively easy to implement. It’s probably just a matter of porting a single, relatively small jsp over to gsp. It is definitely something we should be supporting - I suspect the reason it was never implemented was because it wasn’t an initial requirement for us in Mirebalais, and others are still using the old ui for this. Let’s get this on the near-term roadmap.


@mseaton I’d like to create a jira issue. Which jira project should this be in, reporting or reference application?

@craigappl, the Reporting UI module issues go in the Reporting project in JIRA. Leave fixVersion blank. (And, you can blame me for this silly choice.)

PS- you can set the JIRA component to Reporting UI.