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.

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.

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.

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.

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.

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.

"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...