Like this:

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.

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.

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.

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.

Like this:

Now, let’s look at more interesting one that is the ROO generated source code!

As you can see, there are many AspectJ aspects in the com.springsource.vote.domain package. So I’ll firstly try to look at the Choice class which is not an aspect.

Domain object - Choice

Wow! Is that it? Without the annotations, it consists of only two lines of code in the class. Just two variable declarations.

So where are the others?

Check out the Choice_Roo_Entity aspect.

Persistent Object (Aspect)

It appears to be a persistent object class with a persistence manager which means it includes data access logic. This sounds like normal Active Record yet if you closer look at the code, it uses AspectJ’s inter-type declaration to add more attributes and behaviours to the domain object Choice.

This code above is declaring long type id variable to the type Choice to use as an identifier for OR mapping. Because it is declared as a private variable, it is impossible to access it inside the code of Choice but possible only inside this Choice_Roo_Entity aspect.

What about the Choice_Roo_JavaBean.

JavaBean (Aspect)

It has all the getters and setters for the Choice class and again inter-type declaration is used for adding these accessor methods. So an instance of Choice type cannot only behave as a persistent object but also as a JavaBean object. If you look into the jsp file, you can see it is used just like the methods belong to Choice class.
In order to access the variables inside Choice object, the Choice_Roo_JavaBean is defined as privileged aspect.

So as shown above, Choice_Roo_JavaBean is a privileged aspect and therefore it can access namingChoice and description variables which are declared in Choice.

So what is it? It is a mixin. Mixin is a class which provides a functionality to a subclass yet mixin itself is not supposed to stand alone. So a class can collect its functionality by inheriting from one or more mixins through multiple inheritance. However, as we all know, Java does not support multiple inheritance. So to use mixins in Java world, inter-type declarations in AspectJ can be used.

As seen in the aspect code above, a long type variable is added to the type Choice and a getId() method which returns a long type value that is the value in the variable, id, just added by the aspect. So an instance of Choice type can have getId() method even though it does not exist in the Choice class. Therefore, as mentioned, Choice type can have characteristics of both persistent object and JavaBean.

AspectJ is also used to declare Choice type as a configurable type.

Make Choice @Configurable

This code reveals that Choice type has @org.springframework.beans.factory.annotation.Configurable annotation.