« Return to Thread: Wicket RAD and wicket-guice on Wicket 1.4

Re: Wicket RAD and wicket-guice on Wicket 1.4

by wfaler :: Rate this Message:

What I have done (read my previous post, but lower in the thread from what you answered to) is pretty close to what you are stating, but simply by extending the GuiceComponentInjector instantiation listener.

If one has not been been added to the Application, an IllegalStateException with an explanation will be thrown (saying "Guice support must be installed for instantiation by interface bla bla bla").

Hi,

What you are suggesting was the first idea that occurred to me as well. I immediately checked if you supported interface instead of a class there somehow...

Then you can throw an exception stating something like "extension required for use of interfaces..." in case the extension is not on the classpath.

But you do have another problem to solve. In order to inject the right class Wicket-RAD need access to the Guice injector.

This probably means that on startup of the wicket application the injector that is created would have to be passed to wicket-rad and stored somehow for the liftetime of the application... Do you have any such "init process" in your framework that can be extended to support this maybe...

This would be equivalent to doing what you saw in my Application init(), where the injector is passed to the framework by passing in an extension specific object that implements a framework interface:

WICKET-FRAMEWORK.addComponentInstantiationListener(
new WICKET-GUICE-EXTENSION.GuiceComponentInjector(this, INJECTOR)
);

I would imagine this could be solved in Wicket RAD with something like:

WICKET-RAD-FRAMEWORK.addGuiceSupport(
new WICKET-RAD-GUICE-EXTENSION.GuiceComponentInjector(this ???, INJECTOR)
);

The problem being, what is the class/object that represents WICKET-RAD-FRAMEWORK in the example above?

I don't know how closely you have looked at Guice... the more the higher chance this makes any sense to you I guess... I belive this is a generic problem when you want a framework or submodule to take advantage of logic in a parent module without polluting the APIs by passing around the objects...

What do you think?

Oyvind

wfaler wrote:

Agree, there is no need to do much more integration with Guice for components than what has already been done with the Wicket Guice extensions instantiation listener.

However it makes sense for the "data retrievers and populators" in Wicket RAD, such as IChoiceSource et al.

One thought I had was for instance when you annotate something with @DropDownChoice(MyChoiceSource.class), we could instantiate it from the implementation class if MyChoiceSource is an actual implementation class, whereas if it is simply an interface extending IChoiceSource we can delegate the instantiation to Guice.

This would probably mean that you could only map interface -> impl in Guice, but I think that would be good enough, as your interfaces would for the most part only be "marker interfaces" for Guice and Wicket RAD.

What do you think, does it make sense?

The other question of course is whether or not to put the Guice dependency in the core framework, I'm thinking "no", but at the same time the implementation classes for generation (at least by annotation) are in the core, and would almost have to be Guice aware, so maybe having a Guice jar dependency wouldn't be the end of the world, so long as it is not forced on them to actually use.

/ Wille

« Return to Thread: Wicket RAD and wicket-guice on Wicket 1.4