Spring MVC versus Struts

As I continue learning the Spring Framework, the more I like it :)
Spring is composed of several modules, and although there is one Core module, which I should have read first, I began with the MVC module (mainly because I was more comfortable with it).
Comparing the Spring MVC with Struts (which I have already worked with), I find the Spring MVC more flexible and powerful. For example, when we develop a Struts application we normally worry with Actions and ActionForms. Actions are the entry point of any request made to the application, and ActionForms are specialized beans for encapsulating request parameters. And every "functionality" of the application must have one of these.
Spring has a more pragmatic approach. You don't need to have an ActionForm (called Command in Spring) per Action (called Controller in Spring) if you don't want to. There are plenty Controllers from which you can extend, that provide functionality for a variety of situations (multi actions in one class,
simple forms support, wizard-like interfaces, etc).
Another big difference is the Command Class (ActionForm). It can be any POJO (Plain Old Java Object). No need to subclass anything. This way, if you want, you can use your Model Beans along with their property types. The properties can have, in theory, any type you want, as Spring can already handle a large amount of common types (for the others you need to provide your conversion mechanism).

Another great addition is Handler Interceptors. Basically, you can define a chain of classes that "intercept" the call to any Controller, to do some pre-processing and/or post-processing (very useful for authentication issues for example).

There are other differences, mainly to inject some flexibility to the process: you can choose between different ways of deciding which Controller is called, which View is used, etc.

Despite all this, Spring still has at least one shortcoming: documentation. This is a recurrent issue in open source projects. However I feel that a lot of effort is being done to overcome this (the reference manual is very well written, albeit still incomplete). For example, I couldn't find any reference in the web that explained how to use the AbstractWizardFormController (Controller responsible for the wizard-like interface). I hope to post here a small tutorial for it after I'm finished with some experiments...and if in the meantime nobody else writes one ;)

JSTL goods and bads

Although JSTL (JavaServer Pages Standard Tag Library) already exists for a while, only a few days ago I gave it some attention. It's a nice set of tag libraries, specially those for manipulating variables, strings and internationalization...However, I think they got a little bit carried away....I'm talking about the support for SQL queries. Best practices dictate a clear separation between Presentation, Business Logic and Database tiers. They realize that, as they state that large applications should use other means (DAOs, EJBs, etc) to access database. But, even for simple applications I find their usefulness very limited...
What is a simple application ? One that is small ? One that we want to write as fast as possible ? It really can be faster and smaller in some cases (one can have a custom taglib that based on a SQL query can automatically generate an HTML table). But I think sooner or later one have to do some maintenance to the application. And even in this kind of applications we will have more work changing things done this way, than with a clear separation between presentation and database.
But overall, a useful set of tag libraries, as I said before.

Inversion of Control

When I started reading about Spring, one concept kept appearing : Inversion of Control (IoC). IoC is an apparently simple design pattern, but rather interesting. Here's a fast example of how it can be used:
Imagine you have class Foo and class Dummy. Class Foo has somewhere inside, the following lines:

...
Dummy dummy = new Dummy();
dummy.doSomething();
...

Pretty standard stuff :)
This example tells us one thing: there is a dependency between Foo and Dummy. Sometimes we don't want that....we need to use functionalities provided by Dummy, but we don't want to be attached to the Dummy implementation, because there could be several different implementations of Dummy's functionality. And if wanted to use Dummy2 implementation, we would have to change the code for Foo. So, how do we make those two classes independent ? First, instead of using directly the Dummy class we could use a java interface that publishes the functionality we want:

public interface Dummy {

  public void doSomething();

}

And then, create an implementation for it:

public class DummyImpl implements Dummy {

  public void doSomething(){
   ...
  }
}

And in the Foo class we could have:

Dummy dummy = new DumyImpl();
dummy.doSomething();

Now, we call mehods from the interface instead of directly from the implementing class. This is good, but not enough...We still have "...new DummyImpl()" in there. So the dependency isn't gone yet. To get rid of the dependency we can't instantiate the DummyImpl inside Foo. Instead we could have a setter method in Foo that receives an already instantied implementation of Dummy:

...
Dummy d;

public void setDummy(Dummy d){
  dummy = d;
}
...

Now Foo is completely independent of any Dummy implementation. But if we don't instantiate Dummy inside Foo, we need to instantiate it somewhere. Or maybe not....that's where a Component Container comes in: it will instantiate it for us :)
In Spring we can define, in a XML file, the classes that we need to use, along with their dependencies. So if we run our little example trough Spring, we would have to specify the Foo class, the Dummy implementation and their dependency. Next, when we need an instance of Foo, we ask it from Spring. It will then instantiate Foo, instantiate Dummy and call setDummy() on the Foo class. Only then it returns to us an instance of Foo. This is great if we want to change the Dummy implementation: we only need to change the name of the class implementing Dummy, in the XML file. You can read the Spring reference manual for a detailed explanation of how to use this.

There are other Component Containers besides Spring, namely the Pico Containter (note: Spring provides a lot more than just a Component Container). I haven't studied them, though...

You can have a more in-depth (and plain better) explanation of what is Inversion of Control (also called Dependency Injection) in this article.

MVC frameworks

I've been using Struts MVC framework for a while. It's a solid and very popular framework. So popular that sometimes we forget to check what else is there... In my little research I came across with two very different frameworks: WebWork and the Spring Framework.
WebWork seems to have an aproach very similar to Struts. However, it feels like an improved Struts (no more ActionForm's :) ). However, I didn't analyse it too deeply, so I can't tell all the advantages/disadvantages.
To be true I gave much more attention to our second contestant: the Spring Framework. This one is quite different. It's much more than MVC (MVC is just one of the modules). In fact, you can use WebWork or Struts along with Spring...flexibility is the key :)
I'm doing some experiments with it....I'll post some of the things that I find in here.