in case anyone has the same problem..this is my solution so far (a real
world example)
class WorldPhysXModule extends Module {
val world: WorldPhysX = new WorldPhysX
@Provides
@Singleton
@Named("dimensionScale") def dimensionScale(settings: IProperties): Float
= settings.getFloat("dimensionScale")
@Provides
@Singleton
def provideWorld(settings: IProperties) = {
val subStep1: Float = 1f / settings.getFloat("subStep1")
val subStep2: Int = settings.getInt("subStep2")
world.setGravity(0, settings.getFloat("gravity"), 0)
world.setTiming(subStep1, subStep2)
world.setStepSize(settings.getFloat("stepSize"))
world.setEnableContactUserReport(true)
world;
}
def configure(binder: Binder) {
binder.requestInjection(binder)
binder.requestInjection(world);
binder.bind(classOf[GroundPlaneActor]).toInstance(new
GroundPlaneActor(world, "groundPlane", 1000, 0.00f))
}
}
Note that "WorldPhysx" does not know anything about guice, so we have to
access the setters directly..
To ensure that also "World" gets injected, call requestInjection in
configure but dont BIND it here..do that in provides..anyway that's my
fifty cent.
Den mandag den 10. marts 2014 22.36.27 UTC+1 skrev Mikkel Petersen:
>
> Still, since not all classes are injectable (third party) you might need
> to access them and populate them manually..
>
> Den mandag den 10. marts 2014 21.27.38 UTC+1 skrev Nate Bauernfeind:
>>
>> No actually you don't get already bound exceptions. Guice actually treats
>> the injection as a setter based injection (it doesn't care how you name
>> methods; but I tend to use the word register since it seems to suggest not
>> saving the object).
>>
>> So if you're thinking on the Abstract case you'd have something like this:
>>
>> abstract class AbstractThing {
>> @Inject
>> private void registerThing(ThingService service) {
>> service.registerThing(this) }
>> }
>>
>> class Thing1 extends AbstractThing {
>> ...
>> }
>>
>> class Thing2 extends AbstractThing {
>> ...
>> }
>>
>> and in your configure method you can just do:
>>
>> bind(Thing1.class).asEagerSingleton()
>> bind(Thing2.class).asEagerSingleton()
>>
>> And the magic just happens. It doesn't matter if Thing1/Thing2 are in the
>> same module or separate modules as long as the ThingService exists
>> somewhere and are being created as part of the same injector. And note that
>> the private classifier allows you to hide the fact that Guice is going to
>> do this for you. So you never have to worry about users of Thing1/Thing2
>> abusing that method (at-least I like making it private; your milage may
>> vary =P).
>>
>> If you bind AbstractThing to Thing1 and to Thing2 you will get an already
>> bound exception. But the AbstractThing class doesn't need to show up in any
>> bindings for the injection to occur.
>>
>> Good luck,
>> Nate
>>
>> On Mon, Mar 10, 2014 at 3:15 PM, Mikkel Petersen <mlp...@gmail.com>wrote:
>>
>>> This sounds like a good idea but wont to get a "Already bound" exception
>>> ?
>>>
>>>
>>> Den mandag den 10. marts 2014 20.26.26 UTC+1 skrev Nate Bauernfeind:
>>>
>>>> Just finished reading through the stack overflow link; thanks for
>>>> sharing it. It reminded me of the following:
>>>>
>>>> I've heard/read/adopted the policy that guice modules should sincerely
>>>> avoid any conditional logic. If you do find yourself with some conditional
>>>> logic try and split your module up by either moving the conditional logic
>>>> into a provider or up into multiple modules and let your application
>>>> choose
>>>> which module(s) based on the appropriate mode(s). It's hard to do, and I
>>>> probably don't have one project that is conditional free in all configure
>>>> methods... but that certainly helps defer the need to inject some things
>>>> into a guice module.
>>>>
>>>> Next, I wanted to point out one pattern I've used quite often when it
>>>> comes to registering objects for some purpose (like listening to events,
>>>> or
>>>> even to enable key-based delegation to that object). Typically you'll have
>>>> a main service you want to register to listen/subscribe on, which I'll use
>>>> the example of a DaoService. Users of the DaoService can subscribe to the
>>>> Dao to listen for events that occur on any sub-class of a type. So some
>>>> handwaving:
>>>>
>>>> class DaoService {
>>>> public synchronized void addListener(Class<T> type, DaoListener<T>
>>>> listener) {...}
>>>> }
>>>>
>>>> public interface DaoListener<T> {
>>>> public void dataAdded(T data) throws Exception;
>>>> public void dataUpdated(T oldData, T newData) throws Exception;
>>>> public void dataRemoved(T data) throws Exception;
>>>> }
>>>>
>>>> And then in my user class (and sometimes this is an abstract base
>>>> class) I use setter injection specifically to register the listener:
>>>>
>>>> class ExampleUser {
>>>> private Listener _listener = new Listener();
>>>>
>>>> @Inject
>>>> public ExampleUser(...) {...}
>>>>
>>>> @Inject
>>>> private void registerAsDaoListener(DaoService service) {
>>>> service.addListener(MyDataType.class, _listener);
>>>> }
>>>>
>>>> private final class Listener implements DaoListener<MyDataType> {
>>>> ...
>>>> }
>>>> }
>>>>
>>>> So, again, in this example I'm decoupling the idea of who is listening
>>>> to what data. Obviously the sender / daoService needs to be around (unlike
>>>> in the event bus example), but now no one ever needs to know about how
>>>> many
>>>> listeners there are (depending on how you store your listeners you may
>>>> need
>>>> to make sure you're not overwriting any other listener in the addListener
>>>> method).
>>>>
>>>> And.. I also use Scala as often as I can, so sometimes pieces of these
>>>> end up in a trait that is easy to mix-in for the repeated functionality
>>>> (like managing the listener map/list).
>>>>
>>>> So.. maybe this would be a good alternative to the multibinding
>>>> extension for you. I've used it with great success (esp. when the register
>>>> method is on an abstract base class).
>>>>
>>>> Good luck and happy Guicing =),
>>>> Nate
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "google-guice" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-guice...@googlegroups.com.
>>> To post to this group, send email to google...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/google-guice.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-guice+unsubscr...@googlegroups.com.
To post to this group, send email to google-guice@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/d/optout.
