Mentawai Approach

So the Mentawai mission was already stated in the previous chapter:

Mentawai Mission wrote:
To be as simple as possible, as joyful as possible, to stay out of the way of the programmer, boosting his productivity!

The Mentawai philosophy and approach to accomplish its mission is:

Programmatic Configuration: Mentawai uses Convention Over Configuration but whenever you need or want to configure your controller, your filters, your validation, your IoC, your AutoWiring, etc. you will use a configuration file written in Java. You will NOT use annotations and you will NOT use XML. Back in 2005 when Mentawai was born, frameworks like Struts were abusing the use o XML, taking away the joy of programming. XML programming is definitely not cool. Annotations programming is not cool either. In 2004 Martin Fowler wrote the following about configuration:

Martin Fowler wrote:
A separate but often conflated issue is whether to use configuration files or code on an API to wire up services. For most applications that are likely to be deployed in many places, a separate configuration file usually makes most sense. Almost all the time this will be an XML file, and this makes sense. However there are cases where it's easier to use program code to do the assembly. One case is where you have a simple application that's not got a lot of deployment variation. In this case a bit of code can be clearer than separate XML file.

(...)

I often think that people are over-eager to define configuration files. Often a programming language makes a straightforward and powerful configuration mechanism. Modern languages can easily compile small assemblers that can be used to assemble plugins for larger systems. If compilation is a pain, then there are scripting languages that can work well also.

(...)

One thing we're seeing in the Java world at the moment is a cacophony of configuration files, where every component has its own configuration files which are different to everyone else's. If you use a dozen of these components, you can easily end up with a dozen configuration files to keep in sync.

(...)

My advice here is to always provide a way to do all configuration easily with a programmatic interface, and then treat a separate configuration file as an optional feature.

Source: http://martinfowler.com/articles/injection.html#CodeOrConfigurationFiles

The separate and independent configuration file in a Mentawai web project is called ApplicationManager. You can call it anything as long as it inherits from org.mentawai.core.ApplicationManager. Below is a simple example of an ApplicationManager:

Or you can use the less verbose versions of the methods:

Shortly after the first stable version of the Mentawai framework was released, I wrote an article for the JavaWorld site emphasizing the need to avoid the XML bloat. Although at that time a lot of people were defending the XML approach, it became very clear to us that the programmatic approach had many advantages:

- Less likely to contain errors or typos because it is compiled before it is loaded by the web application.

- Great IDE integration so that you can take advantage of code-completion, auto-compile, refactoring, inline documentation, etc.

- Great flexibility that only a programming language can offer so that you can use loops, ifs, methods, objects, etc., in other words, you make the configuration adapt to yourself and not the other way around.

- Ability to optionally use a dynamic scripting language such as BeanShell, Groovy, JRuby, etc. so that you can accomplish true dynamic configuration, in other words, changes in the configuration are automatically reloaded by the application without the need to restart the application.

- The good and old JavaDoc to document your configuration methods and classes.

More important than the advantages above is that programmatic configuration is more natural and joyful because we are talking about Java code and not another XML specification. XML is a markup language (not a programming language) designed to provide a platform independent representation of data. Unfortunately, in our opinion, people have taken its usage too far. For an example let's take a look on how Struts2 uses XML to do validation:

<!DOCTYPE validators PUBLIC 
         "-//OpenSymphony Group//XWork Validator 1.0.2//EN" 
         "http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd">
 <validators>
   
   <field name="email">
       <field-validator type="required" short-circuit="true">
           <message>You must enter a value for email.</message>
       </field-validator>
       <field-validator type="email" short-circuit="true">
           <message>Not a valid e-mail.</message>
       </field-validator>
   </field>
   
   <field name="email2">
      <field-validator type="required">
           <message>You must enter a value for email2.</message>
       </field-validator>
      <field-validator type="email">
           <message>Not a valid e-mail2.</message>
       </field-validator>
   </field>
   
   <validator type="expression">
       <param name="expression">email.equals(email2)</param>
       <message>Email not the same as email2</message>
   </validator>
   
   <validator type="expression" short-circuit="true">
       <param name="expression">email.startsWith('mark')</param>
       <message>Email does not start with mark</message>
   </validator>
 </validators>

Source: http://struts.apache.org/2.x/docs/validation.html

Besides this boring and unnatural XML schema you should notice that it is actually mixing Java code with XML code. Some people may say "Who cares?" but our opinion is that this is not joyful or natural. A quick look around the Internet will reveal some more exotic things people are doing with XML.

OpenXava (http://www.gestion400.com/web/guest/tutorial)

OpenXava Site wrote:
OpenXava is a framework to develop easily business applications with XML and Java.

Its virtue resides in the fact that the heart of our applications is XML instead of Java.

Xalan: http://www.ibm.com/developerworks/library/x-xalanextensions.html

IBM Article wrote:
The Xalan XSLT processor can invoke almost any method in almost any Java™ class in the classpath.

Please note that we have nothing against these projects and that they surely have their scenarios, but we believe that XML Programming is definitely not the way to go for agile and joyful web development. The Mentawai approach since its inception was to eliminate all XML and perform any kind of configuration/setup using the Java programming language.

No Annotations: Although Annotations is a great improvement when compared to XML, its usage can also be taken to bad extremes. Plus when you annotate your code all over the place you are really scattering the configuration throughout your code. It is very likely that any change in your configuration will force a full rebuild of your application. Note that because a Mentawai web project makes use of a separate and independent Java class, any change in your configuration will not require a full rebuild. You can change, compile and redeploy just your configuration many times while your main application has not changed. You can even have different configuration files (different ApplicationManagers) that can be applied to the same web application.

Another drawback of annotations is that it will tie your code to the framework being used, in other words, any further compilation of your code will require the framework jar in the classpath. Maybe not a big deal for your actions, but definitely not something recommended for your business model. With the Mentawai approach of having a single centralized Java class for the configuration, this will never happen, in other words, your web application can be totally decoupled from the web framework.

Coming back to the issue of annotation abuse here is how Struts2 use annotations to perform validation:

@Validation()
 public class SimpleAnnotationAction extends ActionSupport {
 
     @RequiredFieldValidator(type = ValidatorType.FIELD, message = "You must enter a value for bar.")
     @IntRangeFieldValidator(type = ValidatorType.FIELD, min = "6", 
      max = "10", message = "bar must be between ${min} and ${max}, current value is ${bar}.")
     public void setBar(int bar) {
         this.bar = bar;
     }
 
     public int getBar() {
         return bar;
     }
 
     @Validations(
             requiredFields =
                     {@RequiredFieldValidator(type = ValidatorType.SIMPLE, 
 fieldName = "customfield", message = "You must enter a value for field.")},
             requiredStrings =
                     {@RequiredStringValidator(type = ValidatorType.SIMPLE,
  fieldName = "stringisrequired", message = "You must enter a value for string.")},
             emails =
                     { @EmailValidator(type = ValidatorType.SIMPLE, 
 fieldName = "emailaddress", message = "You must enter a value for email.")},
             urls =
                     { @UrlValidator(type = ValidatorType.SIMPLE, 
 fieldName = "hreflocation", message = "You must enter a value for email.")},
             stringLengthFields =
                     {@StringLengthFieldValidator(type = ValidatorType.SIMPLE, trim = true, minLength="10" , 
 maxLength = "12", fieldName = "needstringlength", message = "You must enter a stringlength.")},
             intRangeFields =
                     { @IntRangeFieldValidator(type = ValidatorType.SIMPLE, 
 fieldName = "intfield", min = "6", max = "10", message = "bar must be between ${min} and ${max}, current value is ${bar}.")},
             dateRangeFields =
                     {@DateRangeFieldValidator(type = ValidatorType.SIMPLE, 
 fieldName = "datefield", min = "-1", max = "99", message = "bar must be between ${min} and ${max}, current value is ${bar}.")},
             expressions = {
                 @ExpressionValidator(expression = "foo > 1", 
 message = "Foo must be greater than Bar 1. Foo = ${foo}, Bar = ${bar}."),
                 @ExpressionValidator(expression = "foo > 2", 
 message = "Foo must be greater than Bar 2. Foo = ${foo}, Bar = ${bar}."),
                 @ExpressionValidator(expression = "foo > 3", 
 message = "Foo must be greater than Bar 3. Foo = ${foo}, Bar = ${bar}."),
                 @ExpressionValidator(expression = "foo > 4",
  message = "Foo must be greater than Bar 4. Foo = ${foo}, Bar = ${bar}."),
                 @ExpressionValidator(expression = "foo > 5",
  message = "Foo must be greater than Bar 5. Foo = ${foo}, Bar = ${bar}.")
     }
     )
     public String execute() throws Exception {
         return SUCCESS;
     }
 }

Source: http://struts.apache.org/2.x/docs/validation-annotation.html

We believe that Annotations Programming can be as bad as XML Programming, therefore, to avoid this pitfall and to be different from the majority of web frameworks out there, Mentawai has decided to abolish any kind of annotation. The goal is to keep it clean and keep it simple without annotations, the only exception being @Override.

Full-stack: To do a web project before Mentawai was very easy, provided that you knew how to use and integrate close to 10 different Java frameworks. You can use Struts for the controller, JSTL for the JSPs, Hibernate for the persistence solution, C3P0 for the connection pool, Commons Validation for the validation, Spring for Inversion of Control and Auto-wiring, Commons Email for sending emails, Commons File Upload for uploading files, JAAS for authentication and authorization and perharps Tiles for templates, Log4J for logging and OSCache for caching. Everybody will probably agree that this is a Rube Goldberg machine very intimidating for newcomers. But this can be avoided with the abstraction power of any object-oriented programming language. The Mentawai approach is to use high levels of abstraction to shield all this complexity from the web developer. Some of these frameworks were actually incorporated by Mentawai so you don't need to know them to use them. You can start a Connection Pool, something very basic for all web applications, with two lines of code in the ApplicationManager. Under the hood Mentawai will setup and use a C3P0 connection pool for you. Same thing for sending emails. You don't need to know Commons Email to send an email message. You can just use some simple lines of code to send emails from Mentawai and under the hood it will use the Commons Email framework for you. For other features like Authentication, Inversion of Control, validation, etc. Mentawai implements its own simple and high level solution, so you can take advantage of them without having to bring a whole new framework into play. Although the Mentawai goal is to be a full-stack solution for web applications, it also offers integration with other frameworks such as Spring, Velocity, JSTL, Hibernate, etc.

Allow me to talk a little bit more about abstraction. With the rise of the Ruby programming language, which I like very much, Java was blamed of being a no pragmatic language and a very verbose language. If you compare Java with Ruby this statement is correct. No question about it. Let's take a look of how Java opens up a file to count its number of characters and how the same program could be done in Ruby.

Now the Ruby version:

Wow! At a first glance it really looks that Ruby is much more pragmatic and less verbose than Java. And it really is. However, with some abstraction power, we can solve this problem and put Java back in the game.

What we did was abstract the complexity inside another object called FileUtils. Some Ruby lovers will complain that we cheated, but now to count the chars of a file in Java has become very easy and pragmatic. That's exactly what the Mentawai framework tries to do for web development. The Mentawai approach is to abstract all the complexity so that the recurrent tasks of every web application become easy and straightforward every time you start a new project.

Convention over Configuration: This approach should be taken for granted by any framework that wants to be simple and productive. Mentawai uses Convention over Configuration (CoC) in many situations and you can even create your own conventions to override Mentawai's one. To have Convention over Configuration means to have defaults for everything and allow the user to change them through configurations.

Some examples of CoC in the Mentawai framework are the directories where the internationalization (i18n) files are located and the location of the JSP files for an action to which no consequence was specified. For example if you have coded a validation filter with the name UserValidation.java, the convention for the i18n file location is: /validation/UserValidation_locale.i18n. If you have the action add() inside the class UserAction.java the convention for the JSP file location is: /UserAction/add.jsp. Of course you can change these conventions with simple configuration methods, but only if you need or want to. And as we have already seen, when you want to escape from the Mentawai conventions you will use programmatic configuration to do so.