Breaking up the Data Set UI Across Multiple Pages

We decided that there were just too many functions to have them all on one page for the data set wizard. The UI is to be broken up in three stages where the user 1) selects the tokens, 2) applies modifiers, and 3) applies filters/cohorts. So, most of the work I've done this week was refactoring all the code into three separate modules and getting all the framework in place to handle this new paradigm.

Here's the first page which provides a way to select tags for narrowing down the tokens, search the tokens, and move the desired tokens to the selection pane:

Here's the second page that lists the selected tokens and provides the interface for applying modifiers to the tokens:

Here's the final page that is really simple right now and just provides the drop down list of available filters/cohorts:

One of the main pain points has been how to keep all of the pages aware of the data input from the other pages as the user toggles between the pages. For instance, the modifier page needs to know which tokens have been selected on the token selection page so that the appropriate token list is displayed on the modifier page. I built a helper class for this so that these variables can be shared in real time and later written to the design as public properties so they will be loaded appropriately if the user wants to later edit the data set. I'm still ironing all of this out as there are a lot of subtle use cases to handle based on the context in which the data set is being modified, but the basic functionality is there.

Developers Guide and Modifier Interface

One of the deliverables I put together this week was the BIRT ODA Plugin Developers Guide for OpenMRS. It contains basic guidelines and resources for those interested in changing or enhancing the OpenMRS BIRT ODA. Any feedback to make things clearer, add more steps, etc. is appreciated.

The most significant thing I did this week was delve even deeper into SWT and create the UI for adding modifications to individual tokens:


Basically, a user selects a token that has been moved to the "selected" list and there is a list of modifiers available for the specific token. There is a checkbox to the right of each modifier to indicate whether or not the modifier should be used for a given token. The right-most column of the modifier table is where the argument can be typed in as appropriate. The two up and down arrows to the left of the table allow the user to change the order of the modifiers since the order may effect how the data is returned. The table and arrows will also dynamically change their height and width to fit the ODA screen if the window size is changed.

There were several resources I used to help understand how to implement some of the different functionality:

• Dynamically resizing columns in a table
• Ordering a table
• Text TableEditor

The next step for the modifier piece is to setup an underlying data structure that keeps track of the modifiers for the different tokens and translate this into a URL request sent to the Logic Web Service (URL format TBD).

Mocking Up the ODA GUI and Adding Token Search

I've been spending time getting more familiar with various components like the Logic Service API (still not working for me) and playing with the data export tool to get a feel for the different types of data that one would want to search for.

I spent some time creating an initial mock-up of the ODA GUI based on the functionality we're wanting to add:


One of the new features is that of adding modifiers to individual tokens. The user can select individual "Selected Tokens" and add and play with Modifiers for each token in the bottom window. Perhaps the "Last" modifier should be selected by default so that the data returned is current patient data by default. Maybe the Modifier section could even be hidden by default and the user can activate it by clicking "Advanced" mode or something similar.

The other new functionality shown in the mock-up on the third "row" is that of the ability for a user to search amongst the available tokens. In an effort to learn SWT, which is the graphics technology used to create the ODA GUI, I implemented a search with the existing BIRT ODA:


You can see on the bottom of the GUI that the search for "DATE" populated the tokens list with all tokens that contained the string "DATE". I didn't spend much time on how and where the search was actually layed out because this will most likely change, but I learned a lot on how to work with SWT. It also took a lot more time than I thought to implement something that seems so simple :) I also reorganized the GUI code some so it's easier to visualize the flow of how things are setup.

Mock Logic Web Service for BIRT ODA is Ready

Since the logicws module is not working with the existing Logic Service API, we wanted to create a mock logicws module that would respond with dummy data without having to communicate with the Logic Service API. This way, we can work on development of the ODA without communicating with the Logic Service API while it is being worked on. The solution is a REST web service module that responds to the exact same URL queries from the existing BIRT ODA.

The initial odamocklogicws module is ready and can be checked out from SVN at http://svn.openmrs.org/openmrs-modules/odamocklogicws (I do not yet have access to add the module to the module repository). The project includes simple JUnit tests that use HttpUnit to make the URL requests to the servlet resources and prints out the resulting fake XML data returned from the odamocklockws. The different servlet resources include token, tokenTag, filter, and data. These tests can also be used when the real logicws module is working to easily see how it responds to URL requests.

The same steps in the BIRT ODA Plugin User Guide can be followed except one should use the new odamocklogicws module instead of the logicws for the BIRT ODA to work (with mock data).