ROO So Cool!!! -04-

Continued from http://blog.kevinlee.io/2009/05/17/roo-so-cool-03/

There are two other aspects which are Choice_Roo_Plural and Choice_Roo_ToString.

"Choice" in Plural Form, "Choices" 

Choice_Roo_Plural declares that the Choice has a method named getPluralName() which returns a String type value, "Choices" which is the plural form of "Choice". I don't really get why it is necessary though. I first thought it might be the name of the table with which the Choice_Roo_Entity matches, yet the table name is choice.

Bind entity com.springsource.vote.domain.Choice on table choice

It is probably for the future use as a name of domain object in plural form may be frequently required when displaying the list of it.

Now, let's look at the last aspect.

toString() method for Choice The last one is Choice_Roo_ToString which declare that Choice has toString() method.

privileged aspect Choice_Roo_ToString {
  public java.lang.String Choice.toString() {
    StringBuilder sb = new StringBuilder();
    sb.append("id: ").append(getId()).append(", ");
    sb.append("version: ").append(getVersion()).append(", ");
    sb.append("namingChoice: ").append(getNamingChoice()).append(", ");
    sb.append("description: ").append(getDescription()).append(", ");
    return sb.toString();
  }
}

It returns String containing the information about Choice which includes all the values of the variables from the aspects as well. This String is used to display the information about Choice object in the view, WEB-INF/jsp/vote/create.jsp.

All these mixins can be good Separation of Concerns (SoC). Each aspect has what should be a concern in a particular mixin only. For example, id and version of Choice are not really a concern of Choice itself as it does not have any meaning for Choice, yet it is very important for OR mapping. Thus it is separated from Choice and only occurs in Choice_Roo_Entity which plays the role of a persistent object.

It is not a completely new ways to write mixin using inter-type declarations in AspectJ (http://today.java.net/pub/a/today/2005/12/15/writing-mixins-with-aop.html). Nevertheless, Spring ROO is still so cool as I have never seen any automatically generated code by Java frameworks uses mixins written using inter-type declarations as a nice way of SoC. I may need to call ROO RSoC (Real Separation of Concerns). :)

OK, I am now running out of time so had better finish this post quickly.

I would just finally like to point out some minor issues I found.

1. An error in dojo JS toolkit.

   dojo JS Toolkit Error

2. An error in roo.css file. CSS Error

   #wrap {
     margin:0 auto;
     position:relative;
     float:center;
     top: 0px;
     left:0px;
     width:800px;
     text-align:left;
   }

   center is not a float value.

3. Using a String's equals() method to test for an empty String. This might be OK for a small application like the ROO example but it can bring about some performance issue for a big application with numerous simultaneous user requests. Performance Issue - Test for Empty String

   So the following code from ChoiceEditor_Roo_Editor

   if (text == null || "".equals(text))

   had better be

   if (text == null || 0 == text.length())

I wrote more details about it here with performance tests. http://blog.kevinlee.io/2009/05/17/test-for-empty-string/

Finally, it's my wish. I found that aspect code is not really supported by the Eclipse functions for Java such as Call Hierarchy and Open Declaration. It would be much better if aspects are fully supported by the Eclipse functions for Java. However, it may have something to do with AJDT not Spring ROO integration.

Phew, I have eventually written this. 😃 Even though I tried ROO approximately two weeks ago, I did not have time to write about it.