XReports Module ReportDesigner Technical Overview
The xreports module uses the purcreports ReportDesigner and ReportRunner widgets.
The ReportDesigner widget is used for the designing of forms while the ReportRunner widget is used for form data entry.
The ReportDesigner widget is embedded in the xformDesigner.jsp page where it attaches itself at a div with an id of "purcformsdesigner"
The FormRunner widget is embedded in the formEntry.jsp page where it attaches itself at a div with an id of "purcformrunner"
The ReportDesigner and ReportRunner GWT compiled JavaScript files are placed in the resources folder under the reportdesigner and reportrunner folders respectively.
In the xformDesigner.jsp and formEntry.jsp pages, the divs you see are configuration parameters for the FormDesigner and ReportRunner widgets. The JavaScript functions are callbacks for the FormDesigner and ReportRunner widgets, while the JavaScript variable named "PurcformsText" holds the text used by these widgets for various labels and user messages.
These two widgets transfer that data in xml format with the xforms module in a RESTful manner.
When one clicks the "Design Xform" link on the openmrs form schema screen, the "org.openmrs.module.xforms.XformBuilder" class uses the form xml template and schema to create an xform which is then sent to the form designer widget to let the user customize the form. When the user is done, the form designer sends back the xform definition and widget layout data which the module stores in the "xforms_xform" table.
When one selects a form on the patient dashboard, the module fetches the xreports definition and widget layout data from the database and passes it to the ReportRunner widget which displays the form to the user for data entry. When the user submits the form, the ReportRunner widget submits the xreports instance data xml (which is identical the one one submitted by Infopath), to the module which passes it through the same form entry queue processing as done for the Infopath forms. The difference here being that the form entry queue API is called immediately instead of waiting for the scheduler as done for Infopath forms.