On 12/14/05, Eduardo Rocha <[EMAIL PROTECTED]> wrote:
you can do the same with the proxy solution, just set an empty context as the current one, and then use setters to replace the proxies. the proxies are lazy init so they will not try to resolve the dependency until you access one of the methods.
a quick google search and here is quote from the hivemind site:
That's the basic concept of Inversion of Control; you don't create your objects, you describe how they should be created. You don't directly connect your components and services together in code, you describe which services are needed by which components, and the container is responsible for hooking it all together. The container creates all the objects, wires them together by setting the necessary properties, and determines when methods are invoked.
http://jakarta.apache.org/hivemind/ioc.html
yes, but wicket is a special case because of its serialization requirements for dependencies.
to each their own i guess.
-Igor
With AspectJ is you can code naturally like
(if you do not use the service in constructor):
MyPage page = new MyPage();
page.setService(mockService);
tester.startPage(page);
tester.assertRenderedPage(MyPage.class );
instead of setting the context mock, which is a nice solution as well.
you can do the same with the proxy solution, just set an empty context as the current one, and then use setters to replace the proxies. the proxies are lazy init so they will not try to resolve the dependency until you access one of the methods.
I don't know if IoC means the container must manage the lifecycle, I
would go for something like "the environment is the responsible".
Using AspectJ you are setting the environment to do DI for you, so
inverting the control; the page (or its superclass) is not looking for
the dependency, an outside code it is.
a quick google search and here is quote from the hivemind site:
That's the basic concept of Inversion of Control; you don't create your objects, you describe how they should be created. You don't directly connect your components and services together in code, you describe which services are needed by which components, and the container is responsible for hooking it all together. The container creates all the objects, wires them together by setting the necessary properties, and determines when methods are invoked.
http://jakarta.apache.org/hivemind/ioc.html
Besides, with AspectJ this kind of DI can be used everywhere, it is
not tied to Wicket pages, it is a general solution, as Spring 2.0 will
bring.
yes, but wicket is a special case because of its serialization requirements for dependencies.
to each their own i guess.
-Igor
