Your recommendation however, is to try as much as possible to rely on only
one injector, that instantiate the different modules as required.
To make my question simple, do you carry around your injector within the
code, or you keep the injection in one place ?
I find myself in many situation where i feel like i need to let the
creation happens at different position in my code. I don't know if it is
normal to have assisted injection everywhere.
I never used providers. But i think we are in the same situation.
Let me take one example.
*I have a Service A that needs a Service B. However, B needs a parameter,
that requires some computation in A first to happens. I always end up
creating an assisted factory with one parameter only? Is that the right
thing to do here ?*
This leads to another question that i have in mind: *Is it ok to have a
parameterized module? In the sense that, you have a constructor of your
module that takes parameters. Why i'm asking this, well i have the
following situation*.
I'm using JavaFX2. I want to encapsulate/modularized the creation of my
interface. In javaFx2 everything happens in the Application.start method
which provide you with the primaryStage.
override def start(primaryStage: Stage): Unit = {
//Create your interface here
//initialized whatever else you may think of here (could launch a thread as
well)
primaryStage.show()
}
I have an interfaceBuilder class that takes the primary stage as parameter.
At least for now. I see two solution here when using guice. Either an
assisted inject, or a module that is parameterized.
Also, when my interfaceBuilder has build the interface, i can get from it
the different Component that it has created. For example, BuildInterface():
AppInterface. where AppInterface, contain the relevant component that i
need: TreeView, StartButton, TextArea, etc.. AppInterface is in a sense a
data Structure.
Now the interesting part here is that, out of those component i need to
create, Services that handle them. TreeViewService ( which in my
application, participantViewService) They independently encapsulate the
logic to manage the logic related their component. TreeViewService takes
the TreeViewComponent has parameter in its constructor. In the more complex
version especially for the StartService and the shutDown Service they take
a controler or whatever class that encapsulate the management of the
application as parameter.
*This is the simplified version. but as you can see. At every step of the
way, i need some parameter to be provided for the creation of my service.
InterFacebuilder Service needs the primary stage, The other view Service
needs the the view component created by the InterfaceBuilder and another
component (e.g. Controler) provided by the Application creation Logic. *
How would you deal with that in this case? Assisted Injection,
Parameterized Modules ?
PS: I'm not using the SceneBuilder of JavaFX2
On Thursday, August 21, 2014 10:53:18 AM UTC+2, Thomas Broyer wrote:
>
>
>
> On Thursday, August 21, 2014 8:43:18 AM UTC+2, Jochen Wiedmann wrote:
>>
>> I'm not sure, whether I get you right. But to me this sounds like a
>> situation where I would create child injectors and somehow make sure that
>> they are accessible. For example, in a web application, I might create a
>> parent injector for the whole web application. And, for any HTTP Request, I
>> might create a child injector with request specific data (a database
>> transaction comes to mind) and store that in a ThreadLocal.
>>
>> OTOH, my example might interfere a lot with scopes. But, to be honest: I
>> never really understood what scopes are good for.
>>
>
> Scopes would be a good fit when child injectors don't work. E.g. you have
> some object that's a singleton or quasi-singleton (because reasons; part of
> a framework for instance) but needs access to objects with a shorter
> lifetime (things that would otherwise belong to a child injector in your
> book, but that would be impossible here); in that case, the singleton
> object can be injected a Provider<OtherObject>. When it knows it needs to
> reuse the same OtherObject instance, it makes it so that it calls
> Provider#get once only; when it doesn't care whether it's the same instance
> as before, it calls Provider#get; and whether it gets the same instance or
> another one is not its responsibility.
>
> Also, "child injectors" are not part of JSR330 whereas scopes are, so
> scopes are more "portable" than child injectors, and classes can elect to
> be used in some scopes by being annotated themselves whereas with child
> injectors you'd rely on the wiring of the injectors and not messing things
> up.
>
> (note: Dagger uses child injectors to implement scopes; AFAICT it forbids
> mixing scopes with a Provider<> but that's generally thought of as a bad
> practice anyway, AFAIK)
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/62222a91-741c-44e4-89ca-8c0f9f2eb06b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
