On 11/7/05, Sven Meier <[EMAIL PROTECTED]> wrote:
But your page factory is not a container - it is a factory. After it creates the object it is no longer aware of its existence. If i then create a page with a dependency on the previous page created will that dependency be resolved? no. If you say that the page factory is an ioc container, then i can argue that any class with a factory method is an ioc container.
Is this class its own ioc container?
SomeClass c=SomeClass.createInstance(a,b,c);
Wicket is an unmanaged framework, so the pages do not have a lifecycle that wicket maintains - they are pojos. So how can you expect wicket to provide callbacks for pages when certain events that are outside of wicket's control occur?
-Igor
Hello Igor,
I must object to your statement that my proposed page factory is not IoC:
Nobody says that a Spring context is the only valid container in an
application. The page factory just becomes part of the this logical
container, it is aware of and cooperates with the Sprint context.
But your page factory is not a container - it is a factory. After it creates the object it is no longer aware of its existence. If i then create a page with a dependency on the previous page created will that dependency be resolved? no. If you say that the page factory is an ioc container, then i can argue that any class with a factory method is an ioc container.
Is this class its own ioc container?
SomeClass c=SomeClass.createInstance(a,b,c);
IMHO to satisfy all possible requirements, these hooks shouldn't be
located on the pages.
It is easier to call from stateless code into stateful code (i.e.
RequestCycle -> Page) than the other way around.
Wicket is an unmanaged framework, so the pages do not have a lifecycle that wicket maintains - they are pojos. So how can you expect wicket to provide callbacks for pages when certain events that are outside of wicket's control occur?
-Igor
