Ok here is our next challenge with the Reporting module!
We would like to distinguish between user facing and non user facing report parameters, and we were wondering what would be the recommended way to go?
I had a quick look at the Parameter class and saw its widgetConfiguration member.
So I was wondering if this was intended to be used exactly for that kind of purpose. As in: we would attach a display attribute to the widget config, and then the JSP would read it to decide whether the param should be hidden or visible. Like here somewhere for example?
I’m really not familiar with JSP at all but I would envision wrapping each param widget inside something like:
@mksd, yes - widgetConfiguration is meant to enable more fine-grained control over how a widget renders itself as an input element, typically as a parameter. For example, maybe you have a Parameter that accepts a Location, and you wanted this rendered as a drop-down list containing only those Locations that are tagged as “Visit Locations”. One might code something up so that the Location widget could read from this widget configuration and provide this rendering option.
All of the main Widget code (and the wgt:widget tag) are defined in the htmlwidgets module. This is why this module is a dependency of reporting.
As for your question about the best way to hide non-user-facing parameters, perhaps this could be done in this way. Can you describe a bit more what you mean by a non-user-facing parameter? if it is non-user-facing, is it really a parameter? Why have this as a parameter in the first place? To be more specific, if you have a DataSet that has 3 parameters, and you want 2 of these to be exposed as Parameters on the report, and the 3rd to be set to a fixed value, this is something you would done when you Map the Data Set Definition into the Report Definition.
@mseaton yes, we do not necessarily want to use UI parameters for every report field, but we want to be able to configure the Report Definition differently for each client.
Our module (MKS Reports) would contain all our Report Definitions and these report definitions should be somehow programmaticaly parametrizable (and activated) by another module or by MKS Reports itself if we provide some sort of configuration to it.
@mksd and I are willing to use the Initializer module + config
@mksd, since Initiliazer can not depend on MKS Reports but we can do the opposite the possible scenario would be, as we discussed the other day:
Initializer exposes a service to fetch the report configs (provided maybe as a JSON in the OpenMRS Config folder)
MKS Reports Activator calls the service and fetches the config so to decide if a given report def is to be loaded or not
Each Report Definition would call the service and fetches the config to set the DataSetDefinition values instead of Parameters or fixed values.
Say for the ‘Referred To’ concept, something like: