Ramblings of a Programmer

I started playing around with regular expressions this past week. I am going to use them in the personal project that I am working on to validate different user input data strings. I recently purchased a very good book from Apress called Regular Expression Recipes: A Problem-Solution Approach by Nathan A. Good. They have another book specifically for Java called Java Regular Expressions: Taming the java.util.regex Engine, but I did not know about it before I purchased the first book. It may have helped me with this problem.

Anyway, the book that I purchased has examples for Perl, Python, and shell scripting. Since it was the first example for each recipe, I picked off the regular expressions from the Perl code for the particulat items that I wanted to validate and used that in Java. I was dumbfounded when it did not work. As an example, I used a regular expression to validate an email address. The regular expression looked like this from the Perl example:

/^[-\w.]+@([A-z0-9][-A-z0-9]+\.)+[A-z]{2,4}$/

I spent a couple of evenings after work at home on this problem before I finally figured it out. You should not use the starting and ending slash (”/”) when using any regular expression in Java. Java’s regular expression compiler apparently sees this as a literal character when it compiles the expression and the corresponding validation ends up failing. When I removed those slashes, the validation unit test past and things were grand!

One other thing to remember in Java with regular expressions is that the backslash (”\”) is an escape character. Unfortunately, it is also an escape character in Java. Thusly, you have to use double backslashes for the escape character in your regular expressions in Java. So, in the example above, the first \w should be set in Java as \\w.

Technorati Tags: Java, Perl, Regular Expressions, shell scripting

Whew! Did I get them all in there? I have been struggling lately with the Model-View-Controller pattern. Well, I haven’t been struggling with the pattern itself as much as I had been struggling with how to implement it properly and create unit tests in an SWT/JFace application. Being new to MVC, one struggles with what should be in the controller and what should not. I was trying to put everything in the controller, but that is not always feasible.

In my case, I was unsure about the inherited methods from the JFace Window class, such as createContents(), initializeBounds(), etc. Well, those methods do not need to be in the controller, because there is no interaction with the model. These methods are strictly there to create and initialize the view. The methods that I ended up putting in the controller were only those that dealt with the view with respect to the model.

For instance, in my example application that I put together tonight to play around with this process, I have a Contact class (model), a setup dialog (view), and a controller class. The model contains nothing more than first, middle, and last name strings for this example. It is quite simple. The view is also simple in that it has three Label controls, three Text controls, and two Button controls (Print and Cancel).

My controller class ended up having the following methods:

public void onFirstNameChanged();
public void onMiddleNameChanged();
public void onLastNameChanged();
public void onPrintClick();
public void onCancelClick();

The first three methods are called in the focusLost method for the FocusListener on the respective edit control for each component of the contact name. The onPrintClick method is called when I click on the Print button. It fires the print method on the view and does nothing more than print the contents of the model out to the console in this simple example. The onCancelClick method fires the close method on the view.

I was able to create unit tests for my controller class and the model, but I did not really create anything for the view. The view does nothing more than initialize itself and wait for user input or receives events from the controller. Since all of the major work for updating the model and other user interaction is handled in the controller, then I am not even sure if it matters that there are no unit tests for the view.

I could have simplified this example a little more by combining the view and the model, but since I have most of the classes already created for an application that I am currently working on for myself, I figured I would see if I could get things working with a model that is separate from the view.

I came across an interesting discussion on Martin Fowler’s web site tonight which talks about Model-View-Presenter.  I need to investigate this further.

Technorati Tags: Java, JFace, JUnit, Martin Fowler, Model-View-Controller, Model-View-Presenter, MVC, patterns, SWT