Hi all, Apologies for suggesting that spring-wicket was simply using a service locator pattern. I can see now that the use of annotations does provide better decoupling than a service locator approach. The only real downside I can see with this are:
1. Use of annotations requires Java 5. Ultimately we will all be better off when Java 5 becomes standard, but I think this will take some time. 2. The thing I like about dependency injection is that you can achieve it will POJOs that have no dependency on the IoC container (i.e. dependencies are injected via constructors or setters). I think the reason I like this is that you can focus on building objects that perform a specific task/role, without concern for how it is deployed or wired up to its dependencies. The use of @SpringBean appears to add a dependency on spring-wicket, although I guess you could argue that in reality it's probably not a trivial thing to switch to a different IoC container anyway. I agree that serialisation is also something to be mindful of, and I believe this is important to remember whenever using dependency injection in conjunction with any web framework that may be used in a clustering environment. I have successfully used the transient/lazy lookup approach with HiveMind in a web application (achieved using custom service proxies), which does work well, but yes it isn't really what I was calling real dependency injection. So I do agree that achieving this holy grail of "true" dependency injection everywhere is probably close to impossible in a web application, but it is still something that is nice to achieve where possible. I definitely support the design of Wicket as an unmanaged framework, and would not suggest this should be changed to support dependency injection. In fact I am now starting to think that the power of Wicket's model-based design can really be enhanced with dependency injection. Consider the following use-case: I have an OSGi-based application where I want to allow different bundles (think plugins, components, jars, etc.) to contribute additional pages and Wicket components to the application. Now because these pages are to all run as part of the same application, I would like to have some common components on the page that link the pages together (i.e. a menu, sidebar, etc.). Initially I was thinking that I want to register a Menu component as a service that would be dynamically injected into each page (this was my approach at the start of this thread). At the same time each bundle would be injecting a page link into the model for the Menu component (also registered as a service) so the Menu can provide access to all contributed pages. Now I believe that it's not so important (or simple) to inject components into pages, but rather I should be trying to inject models into the existing page components. So for example, each page would have it's own Menu component, for which the default model could be provided by the page (using a compound model or something like that). Once all bundles are deployed together, the application bundle might provide an alternative Menu model that provides additional links to other pages in the application, which is then injected directly into the Menu component of each page (overriding the model provided by the page). This relies on a couple of things I haven't fully explained here, but in my head it all seems achievable. :) I do really appreciate the work that has gone into Wicket, and I think of all the web frameworks out there, this one is the best I have seen for working with dependency injection. regards, ben -- http://blogs.modularity.net.au/thenextbigthing _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
