Informative Workspace Code Review

General Thoughts on Wicket

It was very interesting seeing Wicket in action for the very first time. I was amazed to see how empty the corresponding html pages were in comparison to their respective Java classes. Based on what I've seen from both Wicket and Stripes, it appears that Wicket is more powerful, allowing the page to be totally controlled from the Java classes (if you want), whereas Stripes seems more centered around form components and links.

Installation

Following the Installation Guide was simple enough. When it came time to modify the Project Overviewer's source code to get it to retrieve my Visual Studio Sensor project, however, I ran into several problems. Most of the problems were self-inflicted, but I did notice that this part of the installation was not documented anywhere (no guides, no powerpoint).

The Code

Overall, the code seems fine. It is well modularized and well commented both internally and with Javadoc comments. Based on what I have seen of Wicket, the code seems to be adhering to the general Wicket practices. One suggestion that I have would be to implement a base class like "PageProject.java" and have "PageIHacky.java", "PageInfoWork.java", and "PageVSSensors.java" extend it instead. This class would provide the functionality of the pages (since I envision them all to be very similar) while at the same time allowing the developer to customize the content as well. All the code would be in one place making it easier to make changes to the system.

System Issues

ant -f verify.build.xml passes, but it only passes the first time you run it per Tomcat instance. Something about the application can only be deployed and undeployed once per Tomcat instance on my computer. After talking with Fei about this, it seems that the JVM is somehow locking up the folder so it doesn't allow the web application to be undeployed (meaning it can't be redeployed properly). Because of this, the Project-Overviewer is no longer available to be used.

Documentation Issues

Overall, the documentation was pretty decent. The Installation Guide was intuitive enough, but is somewhat geared toward a user who has worked with Java, Tomcat, and environment variables before. While this may not be a large problem since the typical user of this application would more than likely be a programmer, providing a little more detail would not hurt.

Another thing that I did notice about the documentation was that the Developer's Guide did not mention anything about Wicket except that certain Wicket jar files are required libraries. Because Wicket is such a large portion of this project, acknowledging its role in the project and providing links to tutorials, examples, and other sites of interest would be a definite enhancement to the guide.

Is it Helpful?

The general goal of the application--to provide an overview of the project--is certainly a noble and worthy cause. Software engineers and developers would all like to be able to see an overview of the status of the project. However, while the goal is sound, the application itself could be better. The single directory listing of all files within the project takes up a lot of screen real estate. Right now, the project overviewer project itself takes up 2 full screens to display all of its contents. The disturbing part is that it isn't even that big of a project. Imagine a project with thousands of modules and hundreds of packages. How useful would the project overviewer be in its current format with respect to that project? Would users be willing to scroll through all those files? And if not, would users be realistically able to see what is the project overview these? These types of questions must be considered before development continues.

One suggestion that I have is to look into ways to better organize lots of content when space is an issue. Maybe displaying the files as parts of different categories such as "Most Modified", "Least Modified", etc. would allow users to get a general feel for the system without having to look through all the files.

Conclusion

While this project may still be in the early development stages, I think there is a nice foundation here from which a full fledged web application can develop. Right now a lot of functionality is hard coded into the application itself, making it very rigid and inflexible. That being said, the parts that are hard coded in seem to work fairly well so it would just be a matter supplying that configuration ability. Since it is meant to be part of the informative workspace, more research should probably be done to figure out whether the current form of this application is in line with what software developers would want to have.