Messages posted by: saoj

Let's start by the simplest Mentawai application so that you can easily grasp the basics.

We first start by preparing the inescapable web.xml file that belongs to the Java Servlet API. You will not be configuring anything in this XML file. We will just setup the Mentawai controller and that's it. Unfortunately this is a requirement of the Servlet API and no framework can escape from it. But rest assured that you will not be coming back to this file again.

What we are doing here is setting up the Mentawai controller to handle all requests ending with .mtw, which is the default extension for the Mentawai action. We are also setting up our ApplicationManager (remember that the ApplicationManager is the central Java class responsible for the programmatic configuration of our web application) to be the class examples.helloworld.ApplicationManager. Obs: Starting from version 1.13 you do not need to especify the ApplicationManager class anymore. Mentawai will scan the classes directory looking for it.

Now let's code our action: examples/helloworld/action/HelloMenta.java

Our simple action hello receives an username parameter, checks if it is null or empty, changes it to uppercase and passes it up to the action output. It also places the current time in the action output to be displayed to the user. It can return two results: SUCCESS or ERROR. I will give you a full explanation about the Mentawai architecture later on, but for now let's just go on coding.

We have two JSP pages: index.jsp and /HelloMenta/hello.jsp

index.jsp, which contains the HTML form:

/HelloMenta/hello.jsp, which displays the action result:

The first thing we do on both is to declare that we will use the Mentawai Tags (MentaTags for short) with the "mtw" prefix. On index.jsp we use the mtw:form together with the mtw:submit to create a HTML form. Notice that the action attribute of the mtw:submit tag is "/HelloMenta.hello.mtw". This is the URL (or part of it) that the browser will use to request our action. On hello.jsp we are just using the mtw:out tag to print some action results. As you may have suspected, this tag will print values from the action output.

Now comes the last part, which is our web application configuration. We will start by ignoring the Mentawai conventions (Convention Over Configuration) and configure everything by hand. Then we will use the Mentawai conventions. It is important to know what the conventions are as well as how to escape from them whenever you need or desire.

examples/helloworld/ApplicationManager.java

First recall that this is the class that we have specified in the web.xml file, in other words, this is the class that our application will use as its ApplicationManager. We are overriding the method loadActions to load the action "/HelloMenta". The implementation used is the HelloMenta.class and the method that will be called is the "hello()" method. If the action returns the result SUCCESS the consequence will be a forward to "/HelloMenta/hello.jsp". If the action returns the result ERROR the consequence will be a redirect to "/index.jsp".

That's it. Let's put everything together and run our first Mentawai application. Create a new directory inside your tomcat webapps directory. I used "webapps/HelloWorld". This directory is also called your context path and it separates your application from other ones that might be running in the same tomcat. Place the web.xml file inside the webapps/HelloWorld/WEB-INF directory. Place the mentawai.jar file inside webapps/HelloWorld/WEB-INF/lib directory. Compile your action and application manager (you will need the mentawai.jar in the classpath) and put your classes inside webapps/HelloWorld/WEB-INF/classes. Put your JSP pages inside the webapps/HelloWorld. Remember that the page hello.jsp goes inside webapps/HelloWorld/HelloMenta directory. Alternatively you can click here to download a war file with this example.

Fire up your tomcat, open up your browser and type in the address bar: http://localhost:8080/HelloWorld/

You should now (hopefully!) be seeing your first Mentawai web application.

Now let's check out the Mentawai conventions so that you can see for yourself that you only need to configure when you want to or when you need to. On line 10 of ApplicationManager.java your wrote the action name as being "/HelloMenta" but that could have been omitted as Mentawai assumes the name of the action to be the same name as the action class. As the action class is HelloMenta.class, writing "/HelloMenta" for your action name is redundant. So let's remove it:

The method "hello" is not redundant, but it is definitely not necessary here. If you do not specify the method, Mentawai assumes that the configuration should be applied to all methods (or actions) inside the HelloMenta class. If you specify the method name, then it assumes that the configuration should be applied only for that method (or action). So let's remove it for now:

Now talking about the consequences, which in our case were the forward and redirect to the appropriate JSP pages, Mentawai provides conventions for the consequences as well. If you do not specify the consequence for an action, Mentawai assumes that you want a forward (not a redirect) to a JSP page that will be in the location /action_class/action_method.jsp. So in our example, the convention for the action /HelloMenta.hello.mtw would be to forward to /HelloMenta/hello.jsp, which is exactly the path to our hello.jsp page. (Now you see that choosing /HelloMenta/hello.jsp instead of /hello.jsp had a reason

)

So you can remove the consequence for SUCCESS and let Mentawai use its conventions:

We are left with only one consequence configured for the result ERROR. If you remove that consequence, Mentawai will again use its conventions for the ERROR result, the same way it did for the SUCCESS result: it will forward to /HelloMenta/hello.jsp. This is probably not what you want and that's a good example of a case where conventions will not work. The moral of the story is that you should use conventions to save typing and configuration, but you should be ready to configure by hand when the need arises or because you want to take control instead of letting Mentawai decides by itself through its conventions.

In this chapter we talked mainly about the Mentawai mission, philosophy and approach. We learned that the Mentawai mission is to be as simple as possible, joyful and productive. This is a very important statement that the Mentawai team keeps in mind on each and every modification of the framework, so allow us to emphasize this phrase.

Mentawai Mission wrote:
The Mentawai mission is to be a web framework as simple as possible, joyful and productive.

To accomplish that mission, the Mentawai framework has a very particular philosophy and approach. It uses Programmatic Configuration to make the art of programming more joyful and to escape from the XML/Annotation bloat. As we have seen, a programmatic configuration has many advantages over a configuration done through a markup language such as XML, among them integration with IDE, javadoc, dynamic scripting language configuration, flexibility, compile-time errors, etc.

Mentawai Approach wrote:
To use Programmatic Configuration and avoid any kind of XML and Annotations.

Another key point from the Mentawai philosophy is the use of high levels of abstraction to shield as much complexity as possible from the programmer and to escape from the Java framework salad. Mentawai believes that in order to do a web project in Java you should need as few frameworks as possible.

Mentawai Approach wrote:
To use high levels of abstraction to shield as much complexity as possible from the programmer.

Mentawai Approach wrote:
Avoid the Java framework salad by incorporating other frameworks (respecting their license of course) and implementing the main functionalities of other frameworks in the Mentawai core.

And last but not least, the use of Convention over Configuration (CoC) to provide defaults for all features.

Mentawai Approach wrote:
To use Convention Over Configuration to provide defaults for all features allowing the programmer to change them through programmatic configuration.

Enough of boring theory. Let's get some action now!

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.

Thank you for taking the time to read this book. We understand that your time is precious and that if you want to take the chance of learning yet another Java web framework we better make good use of your time. That's one of the main differences of Mentawai when compared to other frameworks. Its main and ultimate goal is to save your time. It can only accomplish this goal by being as simple as it can be. If it is something very powerful, but complex, like the C++ language for example it will fail. Whoever has programmed in C++, and it is not a guru, will understand what I am talking about: C++ is tricky to get it right. C++ will get in the way of your projects and you will end up spending most of your time fighting with the language instead of getting the work done. Too much power generates complexity which in turn hurts productivity. When I started the Mentawai Web Project I had a very strong principle in mind: KISS (Keep It Simple, Stupid). In my opinion this is the most important principle and design goal of any software project. From the Wikipedia:

Wikipedia - KISS wrote:
The KISS principle (acronym for "Keep It Simple, Stupid") states that design simplicity should be a key goal and unnecessary complexity avoided. It serves as a useful principle in a wide array of disciplines, such as software development, animation, engineering, and strategic planning.

But how do you measure simplicity? If you take a C++ guru and ask him if he considers C++ to be simpler than Java he will probably answer yes. He will say that there is nothing more trivial than memory management, pointers, references, structs, templates, etc. Nobody can say that he is lying. C++ is very simple for him. However in order to be fair when comparing the simplicity of two different languages or frameworks we must take the opinion of someone who has no experience with both languages or frameworks. If we take someone coming from Pascal that has never programmed in C++ and Java before, let him play with both languages for a couple of hours (or days) and after that he comes up with the conclusion that C++ is simpler than Java then I will be forced to think that he is lying or that he does not know anything about programming, abstraction and simplicity.

We also realized early that for Mentawai to acquire high levels of productivity it must be joyful. It must be fun. It must not be boring. And we have a very good example of a big Java failure that probably sent many people to a different career other than programming: Enterprise Java Beans (EJB). EJB (EJB1 and EJB2) was everything but joyful. I am proud of myself for not having to write a single EJB project in my life. Huge XML deployment descriptors, many different classes to do a single thing, many tricks that you must know or nothing will work, crazy integration with non-sense application servers (some costing thousands per CPU) and you have a recipe for a Rube Goldberg Machine. From the Wikipedia:

Wikipedia - Rube Goldberg Machine wrote:
A Rube Goldberg machine is a fabulously overengineered apparatus that humorously performs a very simple task in very indirect and convoluted fashion (thus absurdly violating the principle of parsimony).

The goal of a Rube Goldberg Machine such as EJB, besides making a programming careers very boring and painful, is to kill the KISS principle. Most Java web frameworks are not as bad as EJB (that would be a very hard goal to accomplish), but we felt that they have abandoned the KISS principle. The rise of the Ruby on Rails framework (web framework designed with the Ruby language) had signaled to the Java community that something was wrong. Mentawai comes in the way to rescue the KISS principle and the joy of writing web applications in Java before everybody has moved to Ruby.

Ok, enough talk. Let me tell you why we think Mentawai is simple and joyful.