South of the border, Glenn Greenwald has been doing a pretty good job of showing how mainstream US journalists not only no longer expose law- and constitution-breaking by upper-echelon politicians, but actively support, encourage, condone and support it in their writings. And, about that country's vicious two-tier justice system.

Meanwhile, north of the border, we have a new federal budget. Today on the news, one of our darling Opposition critics was complaining about the Prime Minister's "tax gimmicks" - Harper plans to cut taxes as part of a package to get people spending. Calling this a "tax gimmick" is vicious - money collected by taxes does not originally and automatically belong to the Almighty State - it is taken by force of law from the people that own it. A personal income tax cut, for example, leaves more money in the hands of middle class and working poor. The "gimmick" is in taking this money away from them, then giving it to failing multi-nationals that are probably going down anyway (both because they have totally failed to renew and revitalize their business processes and their products, and because they're being bled out by the labour unions). These are the same multi-nationals whose US CEOs flew to Washington to beg... each in their own private executive jet. A gimmick like that, we don't need. In either country.

The Seam documentation covers this now, but it's a bit short of complete examples. Most of this probably applies to other JSF/JPA deployments too (but please don't ask me how). To make the list of a given enum's values available to the view,  just add one new annotated method to a "Factories" class.

@Name("factories")
public class Factories {

    @Factory("countries")
    public Country[] getCountries() {
       return Country.values();
    }

Because you want to display a user-friendly name in the web form, but store a short and consistent name in the database, the enum must have a "label" or "name" field and a getter method (many enums already do). For example, we'll display Canada in the drop-down but enter the ISO-3166 country code CA in the database.

/** See ISO-3166 */
public enum Country {
   CA("Canada"),
   US("United States"),
   AF("Afghanistan"),
   ...
   ;
   private String longName;
   private Country(String longName) {
       this.longName = longName;
   }
   public String getLongName() {
       return longName;
   }    
   @Override
   public String toString () {
       return getLongName();
   }

You typically want to save the string name rather than the ordinal value into the database (especially with Countries where the list order will change in future as countries split or join!) the @Entity class must be annotated thusly:

   @Column(name="Country")
   @Enumerated(EnumType.STRING)   // default and only other choice is ORDINAL
   public Country getCountry() {
       return this.country;
   }

Then, to select it (display a drop-down), you'd use, for example:

      <h:selectOneMenu value="#{register.personalAddress.country}">
             <s:selectItems var="country" value="#{countries}"
                        label="#{country.longName}" noSelectionLabel="-- Select --"/>
              <s:convertEnum/>
       </h:selectOneMenu>

If you've used another framework than Seam, there's a bit of Seam's beauty: the Seam convertEnum tag fixes the 'orrible mess of having your data classes be required to know about UIComponent (can nobody on the JSF standards committee spell "tier violation"?).

To display the current value in a view-only page,  you just need, for example,

  <h:outputText id="country"
      value="#{person.personalAddress.country.longName}"/ >

The data must be basically spotless for the enum converter to work, so - if you didn't have enumerating check constraints on the database from day one - you may e.g., have to "sanitize" the data a little to ensure there are no non-null but blank values in the database, or convert any lower-case values to upper case to match the enum constants. If not you'll get strange message like the famous "can't find resultList" - always check the JBoss console log for a stack trace!

These can be cleaned with SQL like this, using whatever tool you use to feed raw SQL into whatever database you're using:

   update address set country = 'CA' where country = ''
Or you could set these values to NULL.

   update address set country = upper(country)

To check the values, you can use SQL similar to this:

    select distinct(country) from address

Then it all works nicely, as it should, without any need for EntityConverter or for mixing UIComponents into your data layer. Seam rocks!

If you're not a Java programmer, you might as well run along to the next blog entry below. If you are, how often have you seen - or tolerated - code like this in a library you're using?

try {
     clazz= Class.forName(className);
} catch (ClassNotFoundException e) {
      throw new IllegalStateException(e.getMessage());
}

What's really wrong with this code is that it loses information. The fact that the class requested could not be found is completely obliterated, wasting hours and hours of time amongst all the people who use the API. If the class name is org.foo.Foo, the only message the user gets is:

IllegalStateException: org.foo.Foo

What the user would like to see is something like this:

IllegalStateException: ClassNotFoundException: org.foo.Foo

Unlike the former, that is actually useful, and tells you how to track down the problem. And without having to download, accept licenses on, build a project around, etc., etc. the offending library.

What's even more galling is that all the library maintainer needed to do is write the "throw" line as:

throw new IllegalStateException(e.toString());

You know, the offending version of the code above is only one rung up the latter to hell from code like this:

try {
     // something here
} catch (Exception e) {
}

That is, code that "swallows" an exception. Believe me, in my adventures with numerous web development toolkits, I've seen all of these. And reported them. 

Folks, there's nothing like good error reporting. And this is nothing like good error reporting. Neither, in fact, is any stack trace that the user gets to see, but that's a topic for a later post.