Saturday, April 24, 2010

Back and Forth, but Almost Done

This week has been a fairly productive week. As I indicated last week, we were pretty close to getting it done. We cleaned it up a little bit and submitted the first time on Monday. As soon as I submitted it, I decided to check it one more time. Sure enough, it wasn't working (Yes, I know I should have checked it first). So after making a mess of the ticket page by posting 3 random tickets trying to get the first one off, I just wrote a note and asked to have them all deleted. The problem I was getting was Java out of memory errors. After just trying to work through them for the next day or so, Dr. Matocha did the logical thing and googled it. He figured out that there was a wiki page on the OpenMRS website telling you how to change the settings for Tomcat to fix the memory problem. Once that was done, Tomcat worked way better!

So back on topic. Ben ended up looking at the first patch I posted on Monday and giving us some suggestions. (I was actually working fine because Tomcat was the problem). He made a few suggestions for minor changes, but then recommended some of the logic should be moved around. This was kind of confusing at first, but as it turns out, we did have some things in the wrong places (maybe not wrong, but there were better places for them). We moved all of the image handling parts of creating a thumbnail to the ImageHandler class so now the Tag class simply handles the generation of the correct HTML depending on the obs. The other big change was that he didn't want it dependent on a JS script on the encounter JSP page. This left us with a couple options on how to fix it. He was right in that it should work in such a way that the tag can be used without having to put that JS script in the page. We ended up going with a hidden div that is made visible on hover through CSS. This is not the best way to do it, but it is an okay way to do it. I believe it should be done with JS adding or removing divs from the DOM so that every thumbnail preview for the page doesn't have to load before anyone even needs it.

We resubmitted twice Friday with fixes, and hopefully it is good now. We made all the changes he wanted so now we are just waiting to see if he has any other suggestions.

Sunday, April 18, 2010

Done. (?)

I believe we finally have a solution to the ticket! While I hate to speak too soon, it does appear that we have satisfied all of the requests and requirements of our ticket. I'm just hoping that we did this in a way that will be satisfactory to the powers that be. The final step was in figuring out how to access the thumbnail we created in the preview tag class. This was proving to be much more of a hassle than we had first expected, but it is now working. Basically, in the JS/JSP you can pass another parameter called view. This will then be passed through what seems to be 1000 different classes and methods. It eventually ends up at the image handler classes getObs method (assuming we are talking about a complex ob with an image handler of course). In this method we were able to add a test to see if the view="thumbnail". This allows us to return the generated thumbnail instead of the full size image. We were also able to get the resize method to keep the original image's ratio instead of giving us a set 100x100. The only thing we have left to do is go through our code and clean it up. We plan to submit it back to be committed this week.

Sunday, April 11, 2010

Image handling

We made somewhat of a breakthrough this week. We finally figured out how to create a resized thumbnail from the original image. Using a method that we found online, we were finally able to resize the image. It was a little bit of a problem getting the image from the current obs, but we finally got that working. Naming the resized thumbnail is a little bit of an issue right now. We wanted to just add "_thumb" to the end of the filename before the extension. This means that you have to split the filename before the extension. It just gets kind of messy dealing with all of this. This also means that the name must be split apart in the JS. We are still getting closer, but it is taking longer than we expected. The code is also getting pretty messy. We need to clean it all up and finish out figuring the naming stuff. We also have to figure out how to make the resized image look good. The resized image just looks pretty bad right now, but there are a lot of different options for resizing the image differently.

Saturday, April 3, 2010

Inching closer

After a little time off (due to presentation week and Spring Break), we are back at it. We got a few things finished this week after spending some time trying to get back into the swing of things. One thing we cleaned up was how we were testing the handler type for an observation. We figured out how to test the observation's handler type and Elisee added a method in the Obs class called isImageHandler (I think that's the name).

The other thing left to do was deal with generating a thumbnail version of an image. We thought we actually had some code to make this happen, but it hasn't quite worked yet. I think we are close because we finally have a handle on how things are saved and somewhat of an idea of how to scale an image. Bottom line: we are getting closer.

Monday, March 15, 2010

Custom Tag

We decided the best (easiest?) way to handle our problem is to create a custom tag and add it to the openmrs tag library. With a custom tag, you can have a parameter that the corresponding class can access. So for our tag, we pass in the observation and in the PreviewComplexObsTag class we take that observation and determine what needs to be returned. For ComplexObs that have image handlers, we return a link to the full size image and an icon that when moused over pops up a preview of the image. The popup is accomplished using the jQuery code I found earlier in the semester. If the Complex Ob has a text handler, it simply returns a link to the text document.

We are planning on generating a thumbnail version of a given image on the fly in this tag's class. Getting the image data from the obs and generating a thumbnail isn't actually that hard, but the issue we are having is how to save it to the file system and how to access it later. We figured out that the thumbnail should be able to be accessed using the obsId parameter and the view parameter when calling the get obs method in the servlet.

Sunday, March 7, 2010

The MVC Architecture Confuses Me.

While I do believe that we have been learning some things about OpenMRS and their architecture, Elisee and I are still having some trouble completely understanding the system. I feel like we are missing some fundamental pieces of how this type of project works; one thing that I know I need to get a better understanding of is JSTL. JSTL (JavaServer Pages Standard Library) is how methods are accessed from JSP pages.

Elisee was able to edit some Java code and it changed what was displayed on the webpage when that method was called. We still aren't sure how to apply that to what we need.

I found the controller that handles the requests for an image in a complex observation. It is the WebImageHandler class (extends ImageHandler). When getObs() is called it sets a new instance of ComplexData to the name of the obs passed in and gives it a String value of either the HTML view (an img tag) or the Hyperlink view. The view returned is decided by a parameter passed into the method. This seems like it would be the spot we would want to place a third htmlpreview option, but I'm not sure. It seems like this would make sense for images, but does not help us for complex obs that aren't images. I'm still not sure exactly how to access this. In the obsForm.jsp page they use ${htmlView} or ${hyperlinkView} to get the view that they need. This same thing cannot be used on the encounterDisplay.jsp page because ${htmlView} returns the html view for that encounter page. I don't know how to tell it we are wanting the html view of the current observation.

After what we thought was a lot of progress, these past 2 weeks have been spent digging through code and reading tons. We are still trying to determine the right way to complete this "introductory" project.

Sunday, February 28, 2010

"This probably makes the ticket considerably more complex."

Considerably more complex...that's the theme for the past week. After we got stuck, Elisee and I got on the developer mailing list and posted a couple questions. We then found out that the way we had decided to solve the problem is not the right way to do it. We completed the ticked and it works as requested, but it is not generic enough or written in the right way.

So now we have to go back and figure out how to add an AbstractHandler class and the ComplexObsHandler interface. The problem we are having right now is trying to figure out how to get to the methods from the jsp pages. We really don't know how they access methods from the jsp. The other problem is trying to figure out how the html is actually generated. Hopefully, Josh will figure this out for all of us ha...

Saturday, February 20, 2010

Finally getting somewhere...


I feel like we are finally getting somewhere. Now that we figured out what files we were working with, we are actually getting somewhere with the ticket. After spending some time trying to figure out jsp syntax, I finally got the conditional statement to work.

We were just trying to figure out how to test the obs as the page was looping through them to see if they were of the complex datatype.The first issue with that was that we didn't know how to write a conditional statement in jsp. We found out that an if/else statement is actually written as a when/otherwise statement.

So after we figured out the syntax, we had to figure out how to test for a complex datatype. I found out that each concept has an integer variable called conceptDatatypeId, and that (as far as I can tell) complex datatypes hold the integer value 13. I have been trying to get on IRC to make sure that my assumptions are correct, but I haven't been able to get anyone on there yet.

The issue that I think I have now is that this value (13) is the same regardless of what type of complex datatype (image or text). So I think that I'm going to have to find another way to test the obs.

I also found some good code for a popup preview image. I got it implemented (after fighting with it for a while!), but I'm not even sure that it's exactly what we want. I have it set to popup the image when you hover over the small note (note icon now, we need a small pic icon or something) icon. Also, the value is a link to the data the observation holds. This is what they basically wanted; now we just need to iron out a few of these issues.

The other issue that we have is how to handle thumbnails/preview images. The ticket mentions that they wanted a preview/thumbnail to popup (right now the popup shows the picture (original size)). So I know Dr. Matocha mentioned that we might have to figure out how to generate a re-sized thumbnail version as the image is uploaded. Honestly, I haven't the first clue on how to do this. I spent some time reading through the image handler class, and I kind of understand what is going on but not completely.

To do:
1. Figure out how to test for which handler the complex datatype uses
2. Figure out how to generate a thumbnail when an image is uploaded
3. Make a small icon to replace the note icon

Monday, February 15, 2010

So I guess I'm a little slow...

As it turns out, figuring out how to use complex obs is not nearly as hard as I had originally thought. When we finally got OpenMRS up and running, we found out that we had to install a module to add a form to a patient. So we were able to figure out how to install a module (that's actually really easy too) and also which modules we needed (or so we thought). We went back and forth between a few different modules at first (HTML Form Entry, FormEntry, and XForms. Right now I'm using just FormEntry, and to add a complex ob, you just have to create a concept of datatype complex. We were confused at first because we thought that something like an x-ray concept was a complex concept (or we thought it would automatically have an image handler). So as you can see, it is much easier to add a complex ob than I made it out to be.

I also spent some time messing around with XForms because I thought that I had to make a form in there that could handle complex datatypes. I was able to figure the complex obs in there also, but I went back and looked at our ticket and I don't think it is referring to XForms at all anyways.

Now, I'm trying to figure out where in the actual code we need to be working for our project. If it were just editing the HTML and JavaScript of a website, it would be super easy to do. I'm just a little confused about where to find the part we need to be working on (and a little confused about jsp).

Friday, February 5, 2010

Why is this not working???

So getting OpenMRS working is a beast. We have yet to get the code working right. The VM is up and running (running a little better with 1024 megs of ram), but the revisions we have tried so far don't work. Ticket 2069 seems to deal with the issue we are having, but that has been marked as "fixed".

We also can't seem to add a patient at all. Attempting to add someone just takes us to a blank page and doesn't actually do anything. We haven't really been able to move forward with our project because we can't get into the program and actually see how to add a complex obs. Hopefully by Monday they will have this bug fixed and we will be able to start digging into adding an x-ray or whatever for a patient.

Sunday, January 31, 2010

Project 1

Well thanks to Josh we are now assigned to Ticket 1801. This is an enhancement to the OpenMRS system intended to improve handling for complex obs on the encounters list. Basically they want things like pop-up divs for images and better ways to handle these different types of information.

We are now just trying to figure out how to jump into a project that is as big as OpenMRS. I feel a little lost looking at the size of the project and the number of documents and modules you have to go through to find what you need. I'm excited about this project; it'll be fun to really get started.

Saturday, January 23, 2010

All Software Should Be Free...

The documentary Revolution OS seemed to have some interesting characters with some far out ideas, but it is an interesting history on the origin and development of open source software. One of these "characters" was Richard Stallman. He believes that all software should be free. He does not thing that there is a place for proprietary software at all. Personally, this is a little far-fetched. While it would be nice if everyone was willing to share their work; it is unrealistic. Free/open source software definitely has its place, but I think that proprietary software is a good thing too.

I thought that it was also interesting that the guys in the software engineer industry were shocked that this collaborative development style worked at all. They said that everything up to that point indicated that developing software this way would not work. The concept is intriguing; people from all over working together.

OpenMRS…

Elisee and I are looking into working on the complex observation list in OpenMRS. This ticket involves displaying links to the appropriate data held in the list. We found out complex obs are any observations that do not fit in the normal obs table. This might include narrative reports, images, or sounds. Part of this will be to make a popup div that shows a preview of the picture.