It's been quite a while since the last time I mentioned genesis here. One of the reasons is I've been working on it a lot and there isn't much time left to blog about it. Hopefully I will be able to do so more often.

We have just released genesis 3.0 after almost two years and a half of development. genesis is all about making the development of enterprise desktop applications easier. To accomplish that, genesis provides UI-related features and also a neat way of building and integrating with the back-end of your application. For now, let's focus on the desktop itself.

genesis 3.0 comes with full support for Swing, SWT and Thinlet. It supports binding, validation, actions and conditions. Let us say that for the desktop it tries to address nearly the same problem space as JSR-295 (Beans Binding), JSR-296 (Swing Application Framework) @Actions and JSR-303 (Bean Validation), but there are enough conceptual differences between them (besides supporting SWT and Thinlet out of the box, of course). I've already explained the basic UI binding functionality last year, so here I will try to show why the genesis approach is better.

First, genesis works with an UI model, instead of plain binding. This means your JavaBean represents the UI data plus the presentation logic behind it. It makes your presentation logic UI toolkit-independent, testable and self-contained. It also doesn't require PropertyChangeListeners at all. Consider the most basic binding example in genesis docs:

@Form
public class LoginForm {
   private String user;
   private String password;

   public String getUser() {
      return user;
   }

   public void setUser(String user) {
      this.user = user;
   }

   public String getPassword() {
      return password;
   }

   public void setPassword(String password) {
      this.password = password;
   }

   @Action
   public void login() {
      System.out.println(getUser());
      System.out.println(getPassword());
   }

   @Action
   public void clear() {
      setUser(null);
      setPassword(null);
   }
}

If you were to do the same with JSRs 295 and 296, you would have to create a JavaBean with PropertyChangeListener support, fire property changes on setters and also create two @Action methods in your view that access your bean. As the number of properties, beans and actions involved in a view increases, your code with genesis would still be self-contained and testable, while JSR-295 would require individual bindings to be produced and your actions would be tightly coupled with Swing, manipulating your beans as value objects.

genesis also comes with some unique features of its own, such as declarative conditions. Let's analyze the classic dependent comboboxes issue: whenever the selected country changes, the state list should be reloaded. Here is what it takes to implement this with genesis:

@Form
public class StateSelectionForm {
   private Country country;
   private State state;

   @DataProvider(widgetName="countryTable", objectField="country")
   public List populateCountries() {
      return // business logic to retrieve countries
   }

   public Country getCountry() {
      return country;
   }

   public void setCountry(Country country) {
      this.country = country;
   }

   @DataProvider(widgetName="stateTable", objectField="state")
   @CallWhen("genesis.hasChanged('form:country')")
   public List populateStates() {
      return // business logic to retrieve states
      // Notice getCountry() will return the selected country
   }

   public State getState() {
      return state;
   }

   public void setState(State state) {
      this.state = state;
   }
}

So genesis will automatically invoke the stateTable @DataProvider whenever the selected country changes.

There are many other features and things to explore and I hope I can show them here in the next few days. The Brazilian Portuguese users list is quite active these days and there is of course an English users list. Check out genesis and let me know what you think.