WattDepot Status: Progress Retarded

It has been three weeks since this semester began and already is the first milestone for Software Engineering coming up next week.

What I thought to have started out strong with the initial setup and progress with WattDepot-Apps, has suddenly taken a huge bump in our road to completion. Although I can't blame anyone or anything in particular, a snag was bound to happen within the three weeks of working on this project.

To re-iterate our final project deliverable, WattDepot-Apps, was set to complete three stand-alone applications for the WattDepot service. This included:

• WattDepot Visualizer
• WattDepot Browser
• WattDepot Monitor

Our main focus was to work on each project before moving to the next. We compromised that it was better to have one completed, if not, near completed project, than having 3 partially functioning one.

By the end of this week, it will mark 1/4 of the semester gone by, which means the semester is in full swing, with midterms coming up, I believe it will be even more difficult to keep up the progress we once had.

For this past week, the momentum we had died down and we stood a more steady approach to things. Our weekly meeting with Robert Brewer, the WattDepot Wiz, was canceled due to inactivity. What we set out to finish by today was a working version of Visualizer with advanced User Interface components, meaning multi-select menus for sources and data types, and the initial setup of the Browser page.

What we did accomplish though is getting the Multi-select menu to render all the sources of WattDepot, setting up JavaScript to accommodate erroneous option selection, and re-designing page layout to better suite the new User Interface components.

The problems we encountered were between the different constructs we were using to get the site functioning. The base of our site is Wicket based, which is supposed to interact well with Java, however, we also need to use JavaScript in order to get Google Visualizations up and running. Between these three systems, it was hard to jumble between each of them. The way that Wicket is designed seemed to be a hassle to code JavaScript for what we needed. The most irritating I found with Wicket was that setting Default options for menus is a complete headache. When I converted the source drop-down menu to a "CheckBoxMultipleChoice" I ended up hard-coding a default value in the JavaScript of the page because I could not figure out a simple way to set defaults using Wicket.

For this week, we will have to haul double-time. Getting the multi-source selection is our top priority, once we get that done the Visualizer is pretty much complete. For the Browser page the initial workings is in progress. Unfortunately only half of the functionality can be implemented since half is Source summaries, and the other half is User data. The User data has yet to be completed, and even then, there seems to be permission issues with viewing non-public user information.