Fourth Week of Coding - Date Range Filtering

Just completed another exciting week and now it's almost a month after coding started. During this week, I modified the class diagram posted in my previous blog to have some fields like hiNormal,hiCritical, hiAbsolute,lowNormal,lowCritical and lowAbsolute in the UIConcept class. The purpose is to indicate any abnormal values of observation. Using this values, abnormal flags are indicated in red text as show below.

I will use a more effective way to show the abnormal flags in the future.

As the next task, I worked on date range filtering of Patient data. I did some search about possible widgets to use for the date range selection. DatePicker and Slider were my choices. After reading more, I used GXT's DateField (which has DatePicker popup) widget for date range selection. Using a slider widget was not a good choice in my opinion since it will be difficult to select accurate values. Using the feature of the GXT DatePicker widget which allows to specify a Max and Min value of dates to be selection-enabled, I achieved the objective. This widget will only allow to select dates between the range the patient has records.

I modified the service method which retrieve patient data to have additional parameters in order to enable date range filtering. I am happy that we reached the mid-term goal roughly by finishing this task. But there will be much more improvements in these features.

The next feature I am planning to have is filtering data by Concept. Once this features is implemented, the user will be able to filter patient data according to the Concepts related to the observations of that person. I started working on this and looking forward to finish it by next week.

In the mean time I received the Google's welcome package. It included a note book, pend and two stickers. Also the payment card as well :) .

Looking forward to keep my passion growing...

Third week of Coding - Modeling the Transfer Objects

As mentioned in my previous post, during the third week I worked on the modeling the required API classes in the GWT client side. When using GWT-RPC, the transfer objects should be serializable. The bean class can implement either java.io.Serializable interface or the IsSerializable provided by GWT library. When the GWT module is compiled using the GWT compiler, it will create these bean classes in to javascript and package them in the generated folder, which is used as a resources in the OpenMRS module. I came up with a initial version of the class diagram and it can be modified later on when requiring more details. The diagram below shows the initial version of the class diagram.

I added these classes to org.openmrs.modules.flowsheet.gwt.model package and modified the FlowsheetServiceImpl to use these classes. The image below shows the output I got.

Last Thursday I presented my project's first demo to the OpenMRS community during the developer call. I explained the project, integration of GWT-RPC to the module etc. I got good feedback and valuable suggestions from the community to handle huge amount of data. I am reading more on the suggestions to decide on the most suitable methodology. It was a great experience for me to present the demo to such a experienced group of developers. Their encouraging words always motivate me to give my best. Special thanks to my mentor Syfor guiding me to present the demo successfully.

Awaiting for many more excitements and experiences...

GWT Integration to the Flowsheet Module

As mentioned in my previous post, during the second week of coding, I started figuring out the way to integrate GoogleWebToolkit(GWT) to the Flowsheet module. As I expected, it was a challenging task since I needed to find out the integration points. My thanks to my mentor Sy and the OpenMRS developer Daniel Kayiwa. Daniel has already done some work related to GWT in his Xform module. I am happy that I could find out the way to integrate GWT. Thanks to the folks at ##gwt IRC as well. I have written the details about the integration in the module wiki page. Here I will talk more about the problems I faced and how I managed to solve them.

I faced two major problems during the integration:

1. I used a div tag id "flowsheet" in the GWT UI code to get the RootPane. But since my module name is "flowsheet", there was already a div tag defined with the id "flowsheet". When I used the same id in the JSP to hold the GWT UI, there was a conflict and the GWT was not rendered properly. When I inspected via Firebug, I found that the content window retrieved by the new div area was null. But I couldn't figure out at the first try that the name duplication was the actual cause for the problem. While going through the generated code observed in Firebug, I found that there was already a div area with that name. When I changed the name of the new div area, in to some other name, it worked fine.

2. After reading the documentations, I came to know that the servlets under the web/src of a module can be accessed via http:/moduleServlet/flowsheet/flowsheetService. But I took sometime to figure out the format of the URI parameter for the @RemoteServiceRelativePath annotation of the RemoteService interface. The @RemoteServiceRelativePath annotation specifies the relative path of the Service. In this case, the compiled GWT code resides under . So if the relative path is given as /moduleServlet/flowsheet/flowsheetService, it will end up with
http://localhost:8080/openmrs/moduleResources/flowsheet/generated-folder/moduleServlet/flowsheet/flowsheetService. To avoid that, the location ../../../moduleServlet/flowsheet/flowsheetService is used. This will end up in the correct location of the service :
http://localhost:8080/openmrs/moduleServlet/flowsheet/flowsheetService

My next task is to decide on the UI objects to be represented in the client side of GWT. I have already started working on designing a class diagram for this purpose.

The first group of GSoC students presented their project progress during the developer call on last Thursday. This week is the turn for the students belong to the second group. I belong to the second group and eagerly waiting for this Thursday to present my progress to the OpenMRS developer community. I am sure that it will bring me lot of experience. Looking forward to it....