JavaScript and Highcharts

When you work at a smaller shop you get introduced to a lot of technology and you pretty much have to go with the flow. For the past couple of weeks that flow has been down the white rapids of JavaScript for me.

The goal of the project was conversion from flot to Highcharts. Flot offered some very basic graphing and they wanted more eye candy and functionality so they decided on Highcharts. Will cost the company a licensing fee but it will be a much more professional product in the end.

I have not done much JavaScript in the past. I know it is not Java but the syntax is very close so getting up to speed on that was not an issue. Figuring out all the nuances is another story. I have the project up and running now with some final polish so it works better on iPads and Android tablets.

This would be considered a small project. Single page with two tabs. The page contains a dashboard layout control and you can add widgets. Each widget has associated HTML, shared CSS and a JavaScript to query for the JSON data and convert it into Highchart format. We have all the fun of formatted tooltips and configuration settings such as legend position and visibility of data labels.

So where does the fun begin? The whole code / debug cycle is a bit frustrating. I am using Eclipse and Chrome. If I just change a JS file I can save it in Eclipse, hit refresh in Chrome and see the results. If I am changing CSS or HTML I get to clear the cache in Chrome then refresh to see the changes.

Chrome has a decent debugger but you have to make sure you include the JS in the proper file for Chrome to see it as a source file. I had to remove it from a styles.js and move it into a controlling HTML for this to work. Then the break point may or may not work. You end up doing console.log(object) and then just sniffing around in the output console to see what is happening.

Don't forget console.log('Widget is ' + widget); is totally different than console.log('Widget is'); console.log(widget); The first one converts widget to a string which is generally useless. The second set of lines will show widget as an object you can inspect.

JSON.stringify(object) can come in handy at times. You will get circular references for core objects but for looking at return values from the server and what not it works fine. I usually copy that output into Sublime Text 2 and run the JSON formatter on it to get a good look at the results.

Since JavaScript is not strongly typed Eclipse is not a lot of help when it comes to finding variables and methods. You just have to know what is there by opening code and looking around. Not the best way to be productive. You also are not told your code is crap until you run it. I know dynamic languages have their strong points but I really missed this area of strongly typed languages.

Scoping is another bit of fun. If you want to trigger an event from one place and catch it in another, well it works but figuring out the proper scope can be a bit of a pain. It is all up and running but I ended up getting a lot of help from a developer with a stronger JavaScript background than I. In the end I was still unsure why what he handed me worked but I was just happy it did.

Highcharts is a really solid product. I am very happy with its final look. I was able to pull off a number of cool features. I did a lot of web searching to find out how to format tooltips, grab events, set up gradients, use multiple y axis, do stacked bars, etc. It really helped to be able to run jsFiddle sample projects. Guess that is one of the nice things about JavaScript, you can piddle around with it on a webpage before you toss it into your project.

An interesting side project that ended up in main project

We are getting PDF files from a client. They contain medical records with one of the items being the patient ID. My initial task was to find PDF parsing code on the web to pull the patient ID from the file then rename the file to include that as a prefix.

A quick search turned up PDF Box from Apache http://pdfbox.apache.org/ which sounded like it would do what I needed. Grab the download, whip up a simple Eclipse project and I have the text extracted. Very easy to use and understand API.

Of course the next part is where the real work comes in. Have the program respond to command line parameters and if none are provided a GUI is presented to the user. Let them pick the source and destination directories then process the files. Save the last used directories to an INI type file so they don't have to pick the directories every time they start the program.

Once that was working I was told they would really love to have the PDF pages converted to a JPG so they could be imported into our software. Turns out PDFBox can convert to PNG which we can also import. Update the code to handle the conversion. They also wanted to copy the originals of properly converted files to an archive directory. Added that to command line processing and GUI.

I asked since I know now how to use the library to convert PDF to PNG why don't we just import PDF files directly? Sure, why not, do that. I updated the main code base to allow user to choose PDF files along with other image formats. Next I changed the processing loop to handle the page count of each PDF for the import status and did all the code to write the converted pages to the temp directory and then import them as PNG files. All pretty easy stuff and it turns out this is something the clients have asked for over the years.

Before we did not want to import straight PDF files as then we would need a PDF viewer in the code. Adobe used to be pretty good for a C/C++ developer allowing you to embed the viewer using OLE and other API calls but that came to a halt I think around version 9. It has never been a fun task in Java. With the conversion to a normal image format I don't have to worry about any of that. Each page can be rotated, annotated, redacted, etc. using our basic image tools.

Now I asked about the original utility program I wrote. Seems pointless for it to convert the PDF to *page#.png files now that we can import things. This morning I am going to add a checkbox to the GUI and another command line parameter to allow you to control the export of page files which will be off by default. They still need the patient ID extract and rename but probably will not use the page extract. With the code already written it might as well stay in as an option.

Funny how a one off request can turn into something that benefits every customer. There are days you just need to do a little research to find really cool simple solutions to problems. I also got to learn about a new library that may come in handy for other projects. The JAR file is not small but what it does is pretty powerful. We added it as a lazy load JAR to our JNLP file. Hopefully QA does not find any massive issues with the conversion. It worked fine on all the PDF files I tried it on but I know there are a lot of ways for those to be messed up.