Customizability
For any auto generated application, the extent of customizability will be a major concern. Let’s now look into the customizability of Spring Roo based applications.
Depending on the requirements, Spring Roo applications can be customized to different extents, and there are side effects for some of the customizations, especially when we try to modify the data model after customization. For example, when you add a field after doing the customization, some times, you may need to tweak the code a bit.
UI Customization
Look and Feel: User interface is the area where maximum customization is required, because the end user directly interacts with it. You may change the overall look of the application by modifying its stylesheets, images and template files. You can also modify the property files to change labels, titles and messages. All these changes are completely non-invasive and Roo will keep these changes intact even when it updates these files.
UI Components: All the html fields are represented as tagx components in Spring Roo. If there is a requirement to change the behavior of a field, it can be done at the component level, so that all the pages will be changed automatically.
Additional Client Side Logic: It is possible to add custom Javascripts to perform client side logic like doing a specific validation.
Page Layout: Roo generated pages will have a normal two column layout. But we can modify the layout by including table or div tags around the fields without touching the field definition. This gives us complete flexibility in page layout.
When new fields are added to the screen, Roo will update the file we have modified. But it will keep our layout tags intact. Once it is re-generated, we may need to properly place the newly generated fields in our layout infrastructure, because Roo doesn’t understand our layout logic. Similarly, when a field is removed, we may need to readjust the layout of other fields.
Business Customization
In some cases we may need to add additional business logic, other than simple validation and persistence.With the help of newly added service layer, this is very easy to achieve. By default, the service implementation class will be empty and the actual implementation will be in ITD file (Click here, if you are not familiar with ITD). You can define the same method in the implementation class with additional logic, and Roo will automatically remove the default method from the ITD file.
Introducing New Functionality
There could be certain functionality which are complex and will not match to any CRUD operations. Eg. A flight availability search. You may need to create the entire layers for such functionality without the help of Roo and update the menu generated by Roo to give link to the new functionality. Depending on the modularity requirement, new functionality can be implemented as new classes or as additional methods in existing controller and service classes. In some cases, it will be possible to reuse the auto generated persistence logic itself and we just need to create the screen and business logic. If we need to update persistence logic as well, we may modify the entity (if we are using active record pattern) or add a new dao class. It is absolutely ok to mix Roo and “non Roo” functionality in a single application. However it is recommended to use a technical architecture which matches with Spring Roo architecture, ie and architecture based on Spring and Spring MVC.
NFR Support
Adherence to Non Functional Requirements is important for any enterprise application. Let us investigate how the well the NFRs can be addressed in a Roo based application.
|
