There is one inconvenience that hinders our progress: the DataSource object that we use to obtain either the whole list of celebrities or a selected celebrity is currently stored as a property of the CelebritiesList page. This is not convenient as we are planning to access this object from different pages, and  the changes we might make to it on one page should be immediately reflected by another page.

In other words, the DataSource should be stored somewhere, we don't care where, but it should be readily available for our code whenever we need it. If you remember our discussion of Inversion of Control and Dependency Injection in the previous article, you can probably guess that we are going to use some kind of IoC here. And since we want the DataSource delivered to us (or injected, like those drinks to our mini-bar) this should be a DI indeed.

You might also remember that the system that takes care of IoC issues in Tapestry 4 is HiveMind. All we need to do is create a HiveMind configuration file, hivemodule.xml, and specify in it that we are going to need an instance of the DataSource class. The first time we request this instance at runtime, Tapestry (well, HiveMind, behind the scenes) will create it for us and store it in some kind of memory. Whenever we request it afterward, the same instance will be given to us (you can see an implementation of the so-called Singleton design pattern here).

Sounds good, now let's actually do all this.