To use gaedo properly with tapestry my first guess was to define a module (in tapestry terms) providing the required ServiceRepository which is the main entry point for gaedo. The GaedoModule class defines that binding for this interface using a build() method:
With the right entry com.dooapp.gaedo.tapestry.GaedoModule: com.dooapp.gaedo.tapestry.GaedoModule in the Manifest.mf file, dropping the jar of the gaedo-tapestry module in our tapestry application classpath is enough to get our module automatically loaded.
As you can see in the build method, we expect a Collection<FinderCrudService> configuration to configure the ServiceRepository properly. This parameter can be provided through the tapestry mechanism for service configuration. So in the AppModule of our tapesty application we just need to define a method call contributeServiceRepository to provide the required configuration to our ServiceRepository.
You might have noticed that we get the ServiceRepository injected in this method. Weird? Who will be instanciated first? The ServiceRepostiory that requires the collection of FinderCrudService to be fully configured or the FinderCurdService which needs itself the ServiceRepostory to be instanciated?
I was thinking some hours about how to solve this problem, trying to remove some dependencies when I stumbled upon the documentation about mutually dependent services injection with the tapestry IoC framework. And the conclusion is: it *just* works! I had nothing to do! This mutual injection just perfectly works out of box! Amazing! The big point is that the tapestry IoC framework is working with Proxies to instantiate objects, and that’s the key of this egg and chicken mistery. Both service can be instantiated in any order, you don’t need to care about it. It will work.
This is quite fascinating. I would like to know more about this project to be able to understand how it really works. Knowledge is power after all. :)
RépondreSupprimer- QualityTapestries.com