« 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:
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
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
oyvindj wrote:I realized that there is probably at least one way support for Guice will have to be supported by Wicket RAD in a similar way that Wicket does.
This is when objects that will be instantiated by wicket-rad are using injected objects. This could in theory be several types of objects.
The one example I have run into is for the different Choice classes where you often wants to call a service layer object to retrieve the options to return. In this case you typically want to inject this service object.
I believe this needs to be supported by the framework (wicket-rad) somehow (maybe through a component instantation listener) to avoid ugliness. I use some some ugly hack to work around this problem currently.
It could also be that I am totally wrong and there is an easy way around the issue that I don't know about...
Oyvind
« Return to Thread: Wicket RAD and wicket-guice on Wicket 1.4
| Free embeddable forum powered by Nabble | Forum Help |
