31. Wicket Katas

We've been tasked with modifying a few example Wicket framework projects as "katas".

Wicket expertise prior to the Katas:

I've been slowly reading through the Wicket book. I think I a vague (albeit better) understanding of the difference between the static and dynamic model system. I would say that my understanding of Wicket as of now is still pretty elementary; I am still a little unsure about the whole component/model relationship and when a component gets re-rendered. Little by little, however, and as I continue to read the book, I've acquired a better understanding of the functions and underpinnings of the framework.

Here's a link to a description of the Katas: ICS413 Wicket Katas

Kata 1A: Duration - 30 min

Kata 1B: Duration - 10 min

Kata 1C: Duration - 2 min

Kata 2A: Duration - 1 hr 15 min

Kata 2B: Duration - 4 hours

Kata 3A: Duration - 30 min

Kata 4A: Duration - 5 min

Kata 4B: Duration - 20 min

Kata 6A: Duration - 2 min

Kata 6B: Duration - 2 min

Kata 6C: Duration - 2 hrs

Total Duration: 8 hrs 16 min

ALL Katas Completed.

Distribution Versions:

Example 01

Example 02

Example 03

Example 04

Example 06

For the most part, a lot of these Katas were adapting already existing code to meet the specifications and weren't all that difficult. 2B, however, took a lot more time to figure out. Here's what we were tasked to do:

Kata 2B: Add a button on the home page with the label, "Make font bold". After the user pushes it, all the text on the page should become bold, and the button label should change to "Make font italic". When the user pushes that button, all of the text should change to italic and the button label should change to "Make font normal". Pushing that button changes the text back to its original state and the button label should now say "Make font bold".

This kata really forced me to examine the interaction between what's presented on the page versus what lives in the java code. I also had to attach a CSS style attribute to the body of the page, which had nested tags, so Wicket's hierarchical structure initially caused errors in the page. After matching the hierarchy with the Java code, I was able to use the attribute modifier function to toggle between font-weight: bold/normal and font-style: italic.

Another problem that I ran into was the toggling of the styles with a submit button. This meant saving a state of some sort, which I solved through use of a session. Prior to this, the flag I used to toggle between styles would not save it's state between page refreshes.

Finally, I had to implement a child class to the Link class. For some reason or another, the button and submit classes did not refresh the page as needed. In order to change the label on the button with each click, I had to create a child class to the link class and implement this toggling of the label within the constructor.

This was by far the most difficult of the 11 assignments.

Probably the second most interesting kata was the following:

Kata 6C: It is often convenient for web applications to consult a properties file when starting up in order to get configuration values. An easy way to do this is with the standard Java Properties mechanism. (See Java in a Nutshell for details on properties file manipulation.) For this Kata, modify your Example06 system to read in a file (if present) located in ~/.example06/configuration.properties. (Note that ~ means "the user's home directory", and that there is a System property in Java that provides this value.) This property file should contain a line like the following: deployment=true

Although not really enlightening in regards to improving my familiarity with Wicket, I did learn about Properties files in Java and how they're used to configure applications. This exercise also helped me brush up on catching exceptions and opening files and streams.

Conclusion

I liked these exercises. I thought they were very do-able and the combination of having templates to work from in addition to other resources (book and Google) really helped to lessen the frustration factor.

I'm starting to appreciate the framework and it's workings. Although by no means have I mastered models, I do have a basic understanding of them as well some of the limitations that the framework presents. E.g., the need to store variables in a session in order to preserve their current values.

The Cheeser example is starting to grow on me too the more I look at it and examine what it can do.

30. WicketChart

Download Wicket Project - Click Here (verify build successful)

In our software engineering class we finally got back to programming. I've been pretty busy over the course of the past week, so I didn't have a chance to turn in the assignment on time. I did, however, feel that this assignment was important enough for me to complete regardless of whether I get credit for it or not.

Our assignment:

Using Wicket, implement a one page web application that provides two components: a form that accepts a variety of parameters along with a submit button that when pressed, generates a GoogleOMeter visualization. To see what a GoogleOMeter is, go to http://imagecharteditor.appspot.com/, then click "Show full gallery", then scroll to the bottom. The last three visualizations are GoogleOMeters.

Your form should allow the user to:

• Set the start and end of the Y axis;
• Set the title
• Set the width
• Set the height
• Provide a data value for the pointer

Prior to doing this, we were tasked with reading the Wicket in Action book:

I managed to read about 100 pages of it. I actually started reading the first 59 pages, put down the book and proceeded to look through some examples first, and then went back, re-read the first 59 pages all over again, and then went on to around page 100 or so.

My Wicket App

I was able to then complete the following web application:

I decided to make the height and width adjustable from both the image attribute as well as the chart's URL (the dimensions of the chart itself are rendered according to dimensions embedded in the URL).

As required, I allowed the user to modify the Y-axis. I also made any change to the Y-axis correspond to a change in the scale of the chart. For some reason, modifying the Y-axis does not affect the chart unless you make the scale identical.

The rest of the user changes were pretty easy to implement once I got things rolling.

As far as testing goes, I first tested to ensure that the page was still rendered after the user entered a value (in this case, changing the chart's width).

The second test involved grabbing a rendered tag value to check whether the user entered width updated the width of the chart. Since the chart's width is stored in the URL of the image, I did a search through the value of the src tag for the width's new value. Both tests were successful.

Software Engineering

I started out with the example provided to us and made minimal changes to it. Each change was tested before moving on. I also commented as I went. As a general rule, I tend to over-comment, although not to the point of being El Capitan Obvious, but enough so that if I were reading it again, the thought process would be clear.

I think as far as software engineering goes, Wicket does allow for a lot more modularity in breaking things up between coders and designers. I've often viewed the source for a page only to be bombarded by code intermixed with html markup. Wicket seems to allow for some common-sense separation between the two - so that coders can do their jobs while designers can do theirs - concurrently.

Summary

Overall, I thought that the way this was presented to us was a good way to learn a new language/framework. It's good to start off with some tutorials or a cursory look through a book and then dive into code after that. Then, diving back into the book allowed me to have an even better understanding of things. I think this will serve as a good model for me as far as learning software languages goes.

27B. Decathlon Design 2

Solar Decathlon - DESIGN (Google Project: Team 6)

As part of our first group project in Software Engineering class, we were tasked with creating a full mockup of the solar decathalon house management system using Balsamiq.

My previous post described our group dynamics and how it related to issue-driven project management. This post will focus on the design aspect of our mockup project.

Overall the design process was pretty smooth. I think it really helps that all three of us have had extensive web design experience. We also seem to agree that clarity and simplicity are priorities when it comes to website design.

Noah designed the template, and I thought we did a good job of making thing consistent. We also took great pains to implement rounded corners where possible, as well as trickling down changes from the template down to the individual pages.

Below are some differences between the first and final iterations.

Energy 1st Version:

Energy 2nd Version: Rounded corners, standardized alignment, and some borders have been removed around charts. I think that this has produced a much cleaner look.

Aquaponics 1st Version:

Aquaponics 2nd Version:

Although we all had different ideas of what makes effective website design, I thought we were able to compromise and provide constructive feedback effectively. Since Noah has the most design experience out of all three of us, we usually deferred to his judgement in the end, even though he was still open to suggestions from the rest of the team.

27A. Decathlon Design 2

Solar Decathlon - PROJECT MANAGEMENT (Google Project: Team 6)

As part of our first group project in Software Engineering class, we were tasked with creating a full mockup of the solar decathalon house management system using Balsamiq.

I was paired with Anthony Kinsey and Noah Wooden. I feel quite fortunate to have these two team members, who are both quite competent when it comes to both programming and web design.

We met a total of four times to put together the initial draft of the mockups. Twice over the phone and twice in person over the past week. We then met one final time on Tuesday for about 5 hours to finalize things and standardize things.

The divvying up of work went very smoothly. This was done during the second meeting. During our third meeting we reviewed the template and reviewed a mockup for the security camera feed page that Anthony and I worked on. Subsequent meetings were used to work on our assigned pages.

As for my input on the issue-driven project management, I thought that it worked well in the beginning, but after things started rolling, since we were all working together, the project really seemed to move along without us having to keep referring back to the issues page (shown below) on our Google project site.

I think tracking issues and assigning issues are probably essential when it comes to working in larger projects with more group members. There are probably many times when the group can't all meet together to do work, and issue tracking definitely helps tasks from falling through the cracks.

During most of our ICS classes, I've found it most beneficial to work together as much as possible. This means physically all being located in the same space rather than corresponding through email or IM. This makes it much easier for us to get immediate feedback from each other. It also helps to focus the team, therefore making the time spent more productive.

Our final two meetings were for 8 hours and 5 hours. I thought we were really able to get a feel for what each person's temperament is and also we were able to share a few laughs and even able to show each other some of the web pages and artwork we've worked on for clients.

All in all, I've enjoyed the design process so far - so far, things have been relatively painless and I've got good group members, which I've come to realize in any work situation is the most important thing.