> I've been investigating the possibilities of integrating Wicket and > OSGi with favourable results.
Good. I know of a couple of projects that were build with OSGi, some guys over at Felix and http://www.eclipse.org/proposals/rsp/ are having fun with it too. > However, one major hurdle, which I think > a couple of others have also pointed out here, is that there is as yet > no solution providing "true" dependency injection for Wicket. Without looking for another flamefest, all (or at least most) of Wicket's current committers share the opinion that 'pure' dependency injection can be regarded as a Golden Hammer. We don't think Wicket needs dependency injection - that would only work if we somehow migrated to a managed model. We don't want that, as the big reason why you can just code Wicket apps like you would do with many desktop UI frameworks is that Wicket is a 'plain Java' framework instead of a managed one. Anyway, the kind of flexiblity you want can be achieved with Wicket. Generally, the way to go to create flexible Wicket components/ pages is to employ a factory that builds the pages, and that varies panels. Panels are the basic component for building dynamic component trees - including their markup. There are many examples on this, including for instance the wizard component of wicket-extensions. > I've looked at the wicket-spring examples, and to me this seems to be > using the Service Locator pattern rather than Dependency Injection. @SpringBean MyService service Is that worse than putting that dependency somewhere in some configuration file and handing over your page/ component creation to a framework instead of being in charge of that yourself? It would honestly be my worst nightmare to have to code like that again. > That is fine as a solution, but consider the following example: I want > to be able to register my Wicket pages as services (concept should be > similar regardless of IoC container) and have other > services/components that are (optionally!) able to "inject" additional > components into these pages. Why/ how should a user interface component be regarded as a service? What is your actual use case? I can think of one or two, that are directly related to coding another framework on top of Wicket. For end-users I can only see disadvantages to such an approach. A component is responsible for itself, and possibly it's childs. The component should decide what optional sub tree to build, not some external entity. Though the component could use an external entity (typically a model value) to get the info to decide on the sub tree to build. > With my basic knowledge of Wicket, this example would seem impossible > as there must be a "placeholder" in the page's HTML that will > correspond to each of the components in the page's component tree. So > ultimately it seems the page component count cannot be altered at > runtime. Again, look at panels (and fragments and borders). > Is there something I am missing here? In case you think we are something missing, you could fetch up: 1) an example of how constructing components the 'IoC' way would work from an end-user's perspective. My guess is that you can do that without sarcrifying Wicket's model of 'just java programming' 2) patches that basically 'prooves' it can be done without destroying Wicket's philosphy. Cheers, Eelco _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
