A Noted Path by Theodore Nguyen-Cao

It’s been awhile since I updated this and big things have happened since.

Cutting to the chase: On June 20th, 2009 I married the lady of my dreams, Patcharee Phongsvirajati.

The wedding ceremonies took place at our houses and the reception was held at Foxchase Manor.

Check out some photos taken by a few of the many photographers:

Photography by Mac Pham, my cousin:

Photography by the Pros:

Photography by Cau Duc, my uncle:

Last night Google announced Java support on Google App Engine.

After a bit of toying around, here are my findings.

The Eclipse plugin is pretty slick. Deploying and build is simple.

The dev server that you spin up locally looks to be jetty under the hood.

Objects intended for storage are JDO annotated and after compiling, you run the .class files through the DataNucleus Enhancer which adds additional metadata so Google can map it to BigTable. The Eclipse plugin automatically performs this step for you after compiling. The examples provide a bunch of ant macros to help facilitate building/deploying.

One issue that I had was that the project was building with Java 1.6 and I would get an error after compiling:

Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file

Even though they say they support Java 1.5 and 1.6, I guess this doesn’t work on the Java 1.6 for the Mac. Switching the build to 1.5 allows the DataNucleus Enhancer to run successfully.

Even though they are using JPA, some features have not yet been implemented or supported ( see http://code.google.com/appengine/docs/java/datastore/usingjpa.html#Unsupported_Features_of_JPA)

Overall, I like what I see so far and think this would be great for quick prototypes of web apps/services.

Going through the tutorial, my awesome Guestbook application has been created and deployed.

The defaults in Rails with ActiveRecord is beautiful when you are just getting started and are created everything for the first time. But once you get into it and your database schema becomes a little more solidified, the things that would have been easy to do by relying on the conventions of Rails require a little bit more work.

In my case, I had a form where there was a database column named “num_guests”, representing the number of guests. When the field fails to pass validation, the error messages is something like

Num guests is not a number

Not quite the text that we want. It would be better if it said

Number of guests is not a number

After doing a little bit of digging, I found the human_attribute_name method. You can override this method in your model class to provide alternative names for fields. To change our error message, I did the following

class Reservation < ActiveRecord::Base
  ...
  validates_presence_of :num_guests
  ...
  HUMAN_ATTRIBUTES = {
      :num_guests    => "Number of guests"
  }

  def self.human_attribute_name(attr)
      HUMAN_ATTRIBUTES[attr.to_sym] || super
  end
end

Since Rails 2.2, this method is used to support internationalization (i18n). Looking at it, it reminds me of Java’s Resource Bundles and Spring MVC’s error messages. Messages are defined based off a key and there’s a chain of look ups that get applied to resolve an error’s message.

Although, I don’t see myself doing any i18n work in the near-term, it is cool that we have that option now in Rails.

After reading about the violinist playing in the metro (which happened awhile ago), I think we are, at many times, too preoccupied with ourselves and the things that are happening in our lives when we should be taking a moment or a step back to recognize the great things that are happening right in front of us.

Do you think you would be able to recognize extraordinary talent when it is staring you in the face?

Video for viewing pleasure:

When building dynamic web sites with lots of javascript UI components being created on the client, understanding how the web framework you’re using will process the request and what must be done to update fields accordingly is even more important.

Specifically, checkboxes have always been a pain to deal with. The gotcha with checkboxes are if a checkbox isn’t checked, the request doesn’t send the parameter so it requires some additional checks to detect that the user deselected something that was there to update the field accordingly. I’ve been playing around with the Stripes framework and ran into this issue.

With Stripes, you can render a checkbox using their JSP tag:

<stripes:checkbox checked="true" name="property1" value="yes"/>
<stripes:checkbox checked="true" name="property2" value="no"/>

When the “checked” value is equal to “value” value, Stripes will render the checkbox as checked. So with the code shown, two checkboxes will be shown with the first checked and the second unchecked.

If a user reverses this by unchecking the first, checking the second, and submit the form, the HTTP request will only see that property2=no. Before the form was submitted, “property1″ had a value of “yes”. Now, “property1″ won’t even appear in the request parameters, so we have to do special handling to check for the absent of the parameter to update “property1″ to whatever value it should be when it is not checked.

In Spring MVC with form binding, checkboxes are dealt with a little differently. Using Spring MVC’s form JSP tag, you can do:

  <form:checkbox path="property1" value="yes"/>
  <form:checkbox path="property2" value="no"/>

Assuming your command bean is named “person”, this will generate the following HTML:

        <input name="person.property1" type="checkbox" value="yes"/>
        <input type="hidden" value="1" name="_person.property1"/>
        <input name="person.property2" type="checkbox" value="no"/>
        <input type="hidden" value="1" name="_person.property2"/>

As noted by the docs,

What you might not expect to see is the additional hidden field after each checkbox. When a checkbox in an HTML page is not checked, its value will not be sent to the server as part of the HTTP request parameters once the form is submitted, so we need a workaround for this quirk in HTML in order for Spring form data binding to work. The checkbox tag follows the existing Spring convention of including a hidden parameter prefixed by an underscore (“_”) for each checkbox. By doing this, you are effectively telling Spring that “the checkbox was visible in the form and I want my object to which the form data will be bound to reflect the state of the checkbox no matter what”.

Spring MVC also provides a “checkboxes” tag which allows you to render a list of checkbox boxes without having to wrap the “checkbox” tag around a JSTL forEach.

Hopefully, that gives you some insight into how to work with checkboxes in Stripes and Spring MVC.