Why a web framework needs a DI framework

When I first saw Tapestry 4 and learned that it had it a DI framework built in my reaction was “Hmm.. interesting“. I didn‘t immediately grok the significance. When I saw the DI framework was not Spring, my reaction (along with many others) was “Why??“. Well, it took awhile, but after having benefited from the power of Hivemind in Tapestry I can say I “get it” now.

The thing that makes Tap4 so powerful is that almost everything is pluggable and decoupled. Persisting things to the session (or not) is a service. Writing links with parameters is a service. Just to name a couple. Sure, great, you could do that with Spring right?. Fine, but then let‘s think about how that might look. Somewhere in the Tapestry jar there would be a ginormous XML file with all the services defined. What if you wanted to change one? Ok, unjar Tapestry and search the ginormous XML for the one thing you want to change. Then rebuild the jar. Oh, and be sure to not to screw anything else up while you‘re modifying the XML or Tapestry is broken. Oh, and be sure to do this again everytime there is a new Tapestry release. Sound like fun?

Now let‘s talk about how things actually do work in Tapestry. Let‘s take a real world example: link parameters. In Tapestry, links bind to listener methods. These listener methods can take parameters. But what‘s cool is that the link parameters don‘t have to be simple Strings but can be real objects. So displayCustomer link can bind to a display(Customer customer) method. As long as Customer is Serializable, Tap4 can write a link for it and pass it along. Of course, if Customer is big your links may be pretty out of control ;)

But what really rocks is that you can easily tell Tapestry how to encode link parameters in a diffent way. And what‘s more, you can do this without touching Tapestry directly. This is what Hivemind makes possible. In Hivemind, all the services can be overriden or added to by “contributions“ from your own code. By adding an XML file anywhere on the classpath you can define just the one piece of Tapestry you want to change. This makes some pretty neat stuff possible. On Trails we actually use another project called Tapernate that “teaches” Tapestry how to write links for Hibernate objects by adding to the link encoding service in Tap4. By simply dropping the Tapernate jar on the classpath, Tapestry will now recognize any Hiberate object and write out a link containing the class name and id value. On the receiving side it will then look up the object from Hibernate and pass the method a live object on the the Hibernate session so all lazy relationships work properly. Magic, eh?