Monday, March 8, 2010

Rolling Out Milestone 2: WattDepot-Apps v2.0

Introducing WattDepot Applications version 2.0! The second milestone is here, and with it comes a newly completed application, the WattDepot Monitor, and a whole new look to the WattDepot Visualizer. The past month has been devoted to the improvement of the Visualizer, as well as the implementation of the Monitor. Sadly, the WattDepot Browser is going to have to wait for another developer to pick up as the Visualizer and Monitor took up most of our resources.

Our updated Google Hosting site for WattDepot-Apps can be found here, complete with featured wiki pages for end-users as well as for developers curious about WattDepot and our project. For this latest release, there are 3 new downloads which can be found on the Downloads page. They include the individual .jar files for the Visualizer and Monitor, and the distribution .zip file which contains all the source code for each application.

I will briefly go over each application, and some of the new features. For more information you can look at the various wiki pages here.

WattDepot Visualizer

The WattDepot Visualizer is an application that uses Google Visualization's Annotated Timeline and Table to show data about a single or multiple sources throughout a given beginning and ending date in a WattDepot server.

Here's a screenshot of what the Visualizer looked like for milestone 1:
The major issue the Visualizer had in milestone 1 was that it could only display data about a single source, hence the drop-down menu. But for milestone 2, we were able to get that working properly, and now the Visualizer looks like this:
There was some discussion about the overall layout of the components. In milestone 1, the Display Data and Source started to hang on the left side, but ultimately we decided it would look more efficient if we had all the components at the top going left to right.

When running the Visualizer .jar you can specify three arguments, which are optional. These are the port number which the Visualizer listens through, and the Data and Rest URIs. The Data URI is used to query WattDepot when creating a Google Visualization, while the Rest URI contains sensor data and all information about each source in the server.

One of the tasks I had to do to make the configurable Data URI possible was pass a variable from Java to JavaScript using Wicket constructs. To get started, first I visited the Wicket Mailing List and tried to see if anyone already tried to do what I want. I searched a couple pages, but couldn't find exactly what I needed. There were some variants, but nothing directly I could use. However, searching through Google, I stumbled across a Chillenious' WordPress which was exactly what I was looking for. The post itself was done in '06 so some of the coding needed to be altered, mainly parameterization. What I needed to accomplish a "variable substitution" was to wrap a HasMap around a Wicket component (IModel).

Here's a snippet of the parameterized version:
Here's a snippet of the JavaScript of the variable being substituted:

Overall, the Visualizer works as intended, it may not be the most aesthetically pleasing as it is just a Developer level application, the functionally and groundwork has been implemented and I like how it turned out.

WattDepot Monitor

The WattDepot Monitor is an application that displays the most recent SensorData of a given source. The user simply selects a Source, Interval, and Data Type, and the Monitor will refresh every interval showing the most recent value of the selected data type. The development of this application was solely Wicket, which was an interesting experience. I had to learn by example from sifting through the Mail List and also going through the Wicket API.

During the initial phase of the Monitor Prof. Johnson drew a mock-up of how the Monitor should look like:

For milestone 2, here's what the Monitor looks like:

Much of the design of the Monitor was pretty straight forward. One of the new features that we added was a Portable URLs. What it does is pass parameters through the URL and configure the UI components accordingly. Ideally we wanted to have this feature in both the Visualizer and Monitor, but we only had time to implement it for the Monitor. It makes more sense to have it in Visualizer than the Monitor, but we wanted to start on a more simple case, and maybe the next developer can implement the rest. The components in the Monitor are all Wicket while the Visualizer is Wicket and JavaScript so it may require some modifications to work properly.

Closing Thoughts

It's been a long and arduous past couple months, yet I've learned quite a lot. A big part of it was just learning Wicket constructs, but the practices we used through Hudson, SVN, and Quality Assurance tools, helped carry the project forward as each step we took to create the final product. The weekly meetings helped set what we needed to do and the constant feedback at each development phase ultimately made the finishing touches on both applications.

No comments:

Post a Comment