Home » Modeling » TMF (Xtext) » Inject a different StaticMethodsFeatureForTypeProvider
| Inject a different StaticMethodsFeatureForTypeProvider [message #692217] |
Sun, 03 July 2011 23:53  |
Eclipse User |
|
|
|
Originally posted by:
Hi,
I extend the Xbase grammar and with the XbaseGeneratorFragment i get a
ScopeProvider that extends XbaseScopeProvider. In this class, a
StaticMethodsFeatureForTypeProvider gets injected with
@Inject
private Provider<StaticMethodsFeatureForTypeProvider>
implicitStaticFeatures;
I want to inject a different instance (my own one), and guess this
should be possible using some trick in my RuntimeModule. I have tried
the following:
@Provides
public
org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider
provideStaticMethodsFeatureForTypeProvider() {
return new StaticMethodsFeatureForTypeProvider(); // this is my own
class, not the existing Xbase one
}
This works, but the values that should be injected into this instance
aren't! I think that I somehow must make the Injector create the
StaticMethodsFeatureForTypeProvider, but I don't know how! Can someone
can enlighten me!
Hallvard
|
|
|
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692218 is a reply to message #692217] |
Sun, 03 July 2011 23:59  |
| Eclipse User |
|
|
|
Originally posted by:
I think I found the answer:
@Override
public void configure(Binder binder) {
super.configure(binder);
binder.bind(org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider.class).to(StaticMethodsFeatureForTypeProvider.class);
}
I hope!
Hallvard
On 04.07.11 01.53, Hallvard Trætteberg wrote:
> Hi,
>
> I extend the Xbase grammar and with the XbaseGeneratorFragment i get a
> ScopeProvider that extends XbaseScopeProvider. In this class, a
> StaticMethodsFeatureForTypeProvider gets injected with
> @Inject
> private Provider<StaticMethodsFeatureForTypeProvider>
> implicitStaticFeatures;
>
> I want to inject a different instance (my own one), and guess this
> should be possible using some trick in my RuntimeModule. I have tried
> the following:
> @Provides
> public
> org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider
> provideStaticMethodsFeatureForTypeProvider() {
> return new StaticMethodsFeatureForTypeProvider(); // this is my own
> class, not the existing Xbase one
> }
> This works, but the values that should be injected into this instance
> aren't! I think that I somehow must make the Injector create the
> StaticMethodsFeatureForTypeProvider, but I don't know how! Can someone
> can enlighten me!
>
> Hallvard
|
|
|
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692221 is a reply to message #692217] |
Sun, 03 July 2011 23:59 |
| Eclipse User |
|
|
|
Originally posted by:
I think I found the answer:
@Override
public void configure(Binder binder) {
super.configure(binder);
binder.bind(org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider.class).to(StaticMethodsFeatureForTypeProvider.class);
}
I hope!
Hallvard
On 04.07.11 01.53, Hallvard Trætteberg wrote:
> Hi,
>
> I extend the Xbase grammar and with the XbaseGeneratorFragment i get a
> ScopeProvider that extends XbaseScopeProvider. In this class, a
> StaticMethodsFeatureForTypeProvider gets injected with
> @Inject
> private Provider<StaticMethodsFeatureForTypeProvider>
> implicitStaticFeatures;
>
> I want to inject a different instance (my own one), and guess this
> should be possible using some trick in my RuntimeModule. I have tried
> the following:
> @Provides
> public
> org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider
> provideStaticMethodsFeatureForTypeProvider() {
> return new StaticMethodsFeatureForTypeProvider(); // this is my own
> class, not the existing Xbase one
> }
> This works, but the values that should be injected into this instance
> aren't! I think that I somehow must make the Injector create the
> StaticMethodsFeatureForTypeProvider, but I don't know how! Can someone
> can enlighten me!
>
> Hallvard
|
|
|
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692329 is a reply to message #692218] |
Mon, 04 July 2011 08:25 |
 Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
Don't mix up Guice's Provider<?> concept with your SMFFTProvider!
To change the binding for a specific interface type, it should be enough
to write
Class<? extends interfaceType> bind<interfaceType>() {
return YourImplType.class;
}
So in your case
Class<? extends StaticMethodsFeatureForTypeProvider>
bindStaticMethodsFeatureForTypeProvider() {
return <your impl>.class;
}
Guice's Provider<?> enables you to get multiple instances of the type by
calling get(). It relies on default constructors or constructors with
injected parameters only. Explicit binding of a Guice Provider<?> should
only be necessary if you want to customize the instantiation /
initialization behavior, e.g. when wrapping a external singleton such as
the workspace or the workbench.
Am 04.07.11 01:59, schrieb Hallvard Trætteberg:
> I think I found the answer:
>
> @Override
> public void configure(Binder binder) {
> super.configure(binder);
> binder.bind(org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider.class).to(StaticMethodsFeatureForTypeProvider.class);
>
> }
>
> I hope!
>
> Hallvard
>
> On 04.07.11 01.53, Hallvard Trætteberg wrote:
>> Hi,
>>
>> I extend the Xbase grammar and with the XbaseGeneratorFragment i get a
>> ScopeProvider that extends XbaseScopeProvider. In this class, a
>> StaticMethodsFeatureForTypeProvider gets injected with
>> @Inject
>> private Provider<StaticMethodsFeatureForTypeProvider>
>> implicitStaticFeatures;
>>
>> I want to inject a different instance (my own one), and guess this
>> should be possible using some trick in my RuntimeModule. I have tried
>> the following:
>> @Provides
>> public
>> org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider
>>
>> provideStaticMethodsFeatureForTypeProvider() {
>> return new StaticMethodsFeatureForTypeProvider(); // this is my own
>> class, not the existing Xbase one
>> }
>> This works, but the values that should be injected into this instance
>> aren't! I think that I somehow must make the Injector create the
>> StaticMethodsFeatureForTypeProvider, but I don't know how! Can someone
>> can enlighten me!
>>
>> Hallvard
>
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692361 is a reply to message #692329] |
Mon, 04 July 2011 09:37 |
| Eclipse User |
|
|
|
Originally posted by:
On 04.07.11 10.25, Jan Koehnlein wrote:
> Don't mix up Guice's Provider<?> concept with your SMFFTProvider!
>
> To change the binding for a specific interface type, it should be enough
> to write
>
> Class<? extends interfaceType> bind<interfaceType>() {
> return YourImplType.class;
> }
>
> So in your case
>
> Class<? extends StaticMethodsFeatureForTypeProvider>
> bindStaticMethodsFeatureForTypeProvider() {
> return <your impl>.class;
> }
>
> Guice's Provider<?> enables you to get multiple instances of the type by
> calling get(). It relies on default constructors or constructors with
> injected parameters only. Explicit binding of a Guice Provider<?> should
> only be necessary if you want to customize the instantiation /
> initialization behavior, e.g. when wrapping a external singleton such as
> the workspace or the workbench.
I think I understand this. However, XbaseScopeProvider declares a
provider of a provider class:
@Inject
private Provider<StaticMethodsFeatureForTypeProvider>
implicitStaticFeatures;
And it uses get to get a new instance:
protected StaticMethodsFeatureForTypeProvider
newImplicitStaticFeaturesProvider() {
return implicitStaticFeatures.get();
}
Hence, I thought I needed to make the default creation use my
StaticMethodsFeatureForTypeProvider class instead of Xbase's.
Correct me if I'm wrong.
Hallvard
>
> Am 04.07.11 01:59, schrieb Hallvard Trætteberg:
>> I think I found the answer:
>>
>> @Override
>> public void configure(Binder binder) {
>> super.configure(binder);
>> binder.bind(org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider.class).to(StaticMethodsFeatureForTypeProvider.class);
>>
>>
>> }
>>
>> I hope!
>>
>> Hallvard
>>
>> On 04.07.11 01.53, Hallvard Trætteberg wrote:
>>> Hi,
>>>
>>> I extend the Xbase grammar and with the XbaseGeneratorFragment i get a
>>> ScopeProvider that extends XbaseScopeProvider. In this class, a
>>> StaticMethodsFeatureForTypeProvider gets injected with
>>> @Inject
>>> private Provider<StaticMethodsFeatureForTypeProvider>
>>> implicitStaticFeatures;
>>>
>>> I want to inject a different instance (my own one), and guess this
>>> should be possible using some trick in my RuntimeModule. I have tried
>>> the following:
>>> @Provides
>>> public
>>> org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider
>>>
>>>
>>> provideStaticMethodsFeatureForTypeProvider() {
>>> return new StaticMethodsFeatureForTypeProvider(); // this is my own
>>> class, not the existing Xbase one
>>> }
>>> This works, but the values that should be injected into this instance
>>> aren't! I think that I somehow must make the Injector create the
>>> StaticMethodsFeatureForTypeProvider, but I don't know how! Can someone
>>> can enlighten me!
>>>
>>> Hallvard
>>
>
>
|
|
|
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692412 is a reply to message #692361] |
Mon, 04 July 2011 11:37 |
Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
Using a Guice Provider<>or not is usually the client's choice.
You need to *bind* a Guice Provider<> only if you want to change Guice's
default instantiation strategy.
Am 04.07.11 11:37, schrieb Hallvard Trætteberg:
> On 04.07.11 10.25, Jan Koehnlein wrote:
>> Don't mix up Guice's Provider<?> concept with your SMFFTProvider!
>>
>> To change the binding for a specific interface type, it should be enough
>> to write
>>
>> Class<? extends interfaceType> bind<interfaceType>() {
>> return YourImplType.class;
>> }
>>
>> So in your case
>>
>> Class<? extends StaticMethodsFeatureForTypeProvider>
>> bindStaticMethodsFeatureForTypeProvider() {
>> return <your impl>.class;
>> }
>>
>> Guice's Provider<?> enables you to get multiple instances of the type by
>> calling get(). It relies on default constructors or constructors with
>> injected parameters only. Explicit binding of a Guice Provider<?> should
>> only be necessary if you want to customize the instantiation /
>> initialization behavior, e.g. when wrapping a external singleton such as
>> the workspace or the workbench.
>
> I think I understand this. However, XbaseScopeProvider declares a
> provider of a provider class:
>
> @Inject
> private Provider<StaticMethodsFeatureForTypeProvider>
> implicitStaticFeatures;
>
> And it uses get to get a new instance:
>
> protected StaticMethodsFeatureForTypeProvider
> newImplicitStaticFeaturesProvider() {
> return implicitStaticFeatures.get();
> }
>
> Hence, I thought I needed to make the default creation use my
> StaticMethodsFeatureForTypeProvider class instead of Xbase's.
>
> Correct me if I'm wrong.
>
> Hallvard
>
>>
>> Am 04.07.11 01:59, schrieb Hallvard Trætteberg:
>>> I think I found the answer:
>>>
>>> @Override
>>> public void configure(Binder binder) {
>>> super.configure(binder);
>>> binder.bind(org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider.class).to(StaticMethodsFeatureForTypeProvider.class);
>>>
>>>
>>>
>>> }
>>>
>>> I hope!
>>>
>>> Hallvard
>>>
>>> On 04.07.11 01.53, Hallvard Trætteberg wrote:
>>>> Hi,
>>>>
>>>> I extend the Xbase grammar and with the XbaseGeneratorFragment i get a
>>>> ScopeProvider that extends XbaseScopeProvider. In this class, a
>>>> StaticMethodsFeatureForTypeProvider gets injected with
>>>> @Inject
>>>> private Provider<StaticMethodsFeatureForTypeProvider>
>>>> implicitStaticFeatures;
>>>>
>>>> I want to inject a different instance (my own one), and guess this
>>>> should be possible using some trick in my RuntimeModule. I have tried
>>>> the following:
>>>> @Provides
>>>> public
>>>> org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider
>>>>
>>>>
>>>>
>>>> provideStaticMethodsFeatureForTypeProvider() {
>>>> return new StaticMethodsFeatureForTypeProvider(); // this is my own
>>>> class, not the existing Xbase one
>>>> }
>>>> This works, but the values that should be injected into this instance
>>>> aren't! I think that I somehow must make the Injector create the
>>>> StaticMethodsFeatureForTypeProvider, but I don't know how! Can someone
>>>> can enlighten me!
>>>>
>>>> Hallvard
>>>
>>
>>
>
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692446 is a reply to message #692412] |
Mon, 04 July 2011 12:42 |
| Eclipse User |
|
|
|
Originally posted by:
On 04.07.11 13.37, Jan Koehnlein wrote:
> Using a Guice Provider<>or not is usually the client's choice.
In this case XbaseScopeProvider has made the choice to use a Provider<>,
so I believe I must comply with it.
> You need to *bind* a Guice Provider<> only if you want to change Guice's
> default instantiation strategy.
I think the default strategy for a Provider<X> is to instantiate X,
while I want it to instantiate a specific subclass.
Anyway, it works, so I'm happy!
Hallvard
|
|
| |
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692470 is a reply to message #692446] |
Mon, 04 July 2011 13:46 |
Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
Am 04.07.11 14:42, schrieb Hallvard Trætteberg:
> On 04.07.11 13.37, Jan Koehnlein wrote:
>> Using a Guice Provider<>or not is usually the client's choice.
>
> In this case XbaseScopeProvider has made the choice to use a Provider<>,
> so I believe I must comply with it.
No, as I said, it's the clients choice (the one who gets the component
injected). You just bind an implementation class to an interface or
class. The latter is what the client uses as its API to access this
service. So if a client wants a
@Inject
private Provider<StaticMethodsFeatureForTypeProvider>
implicitStaticFeatures;
it gets a Guice Provider that delivers objects whose type is assignable
to StaticMethodsFeatureForTypeProvider. Any subtype or the type itself
will do. It doesn't matter that StaticMethodsFeatureForTypeProvider is a
class and not an interface. The only difference is that we don't have to
bind a default implementation in this case, as the class itself is bound
by default. You can override that default binding using the same
mechanism as for an interface binding.
>> You need to *bind* a Guice Provider<> only if you want to change Guice's
>> default instantiation strategy.
>
> I think the default strategy for a Provider<X> is to instantiate X,
> while I want it to instantiate a specific subclass.
No, Guice creates an instance of the class that is bound to the specific
interface type. This binding is what you want to change. By default
instantiation strategy I meant calling the default constructor or the
one with only injected parameters.
>
> Anyway, it works, so I'm happy!
>
> Hallvard
Maybe it is a good idea to re-read the documentation on dependency
injection now, and get more familiar with Guice?
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692518 is a reply to message #692470] |
Mon, 04 July 2011 16:15 |
| Eclipse User |
|
|
|
Originally posted by:
On 04.07.11 15.46, Jan Koehnlein wrote:
> Am 04.07.11 14:42, schrieb Hallvard Trætteberg:
>> On 04.07.11 13.37, Jan Koehnlein wrote:
>>> Using a Guice Provider<>or not is usually the client's choice.
>>
>> In this case XbaseScopeProvider has made the choice to use a Provider<>,
>> so I believe I must comply with it.
>
> No, as I said, it's the clients choice (the one who gets the component
> injected). You just bind an implementation class to an interface or
> class. The latter is what the client uses as its API to access this
> service. So if a client wants a
>
> @Inject
> private Provider<StaticMethodsFeatureForTypeProvider>
> implicitStaticFeatures;
>
> it gets a Guice Provider that delivers objects whose type is assignable
> to StaticMethodsFeatureForTypeProvider. Any subtype or the type itself
> will do. It doesn't matter that StaticMethodsFeatureForTypeProvider is a
> class and not an interface. The only difference is that we don't have to
> bind a default implementation in this case, as the class itself is bound
> by default. You can override that default binding using the same
> mechanism as for an interface binding.
As follows, you mean:
public Class<? extends
org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider>
bindStaticMethodsFeatureForTypeProvider() {
return no.hal.ecoretypes.x.StaticMethodsFeatureForTypeProvider.class;
}
>>> You need to *bind* a Guice Provider<> only if you want to change Guice's
>>> default instantiation strategy.
>>
>> I think the default strategy for a Provider<X> is to instantiate X,
>> while I want it to instantiate a specific subclass.
>
> No, Guice creates an instance of the class that is bound to the specific
> interface type. This binding is what you want to change. By default
> instantiation strategy I meant calling the default constructor or the
> one with only injected parameters.
>
>> Anyway, it works, so I'm happy!
>>
>> Hallvard
>
> Maybe it is a good idea to re-read the documentation on dependency
> injection now, and get more familiar with Guice?
I tend to read just enough to get things done. In this case, the
strategy I used worked, but wasn't the cleanest solution. Over time,
misunderstandings like this will be fewer, partly thanks to patient
experts like you!
Hallvard
|
|
|
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692519 is a reply to message #692450] |
Mon, 04 July 2011 16:19 |
| Eclipse User |
|
|
|
Originally posted by:
On 04.07.11 15.09, Christian Dietrich wrote:
>
> i already wanted to file a bug for this since such copy und paste
> subclasses of XbaseScopePRovider just to add some more methods to the
> StaticMethodsFeatureForTypeProvider is annoying. and
> StaticMethodsFeatureForTypeProvider is not easyly subclassable /
> extendable too.
I agree. I have also extended OperatorMapping, and need some copying &
pasting there, too. In general, it's difficult to imagine what parts
that will need to be extended using subclassing, and hence, design a
nice and extendable API.
My example project will give me some experience in extending Xbase, and
will hopefully result in some feedback about what parts are easily
extendable and how things can be improved.
Hallvard
|
|
|
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692852 is a reply to message #692518] |
Tue, 05 July 2011 10:52 |
Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
Am 04.07.11 18:15, schrieb Hallvard Trætteberg:
> On 04.07.11 15.46, Jan Koehnlein wrote:
>> Am 04.07.11 14:42, schrieb Hallvard Trætteberg:
>>> On 04.07.11 13.37, Jan Koehnlein wrote:
>>>> Using a Guice Provider<>or not is usually the client's choice.
>>>
>>> In this case XbaseScopeProvider has made the choice to use a Provider<>,
>>> so I believe I must comply with it.
>>
>> No, as I said, it's the clients choice (the one who gets the component
>> injected). You just bind an implementation class to an interface or
>> class. The latter is what the client uses as its API to access this
>> service. So if a client wants a
>>
>> @Inject
>> private Provider<StaticMethodsFeatureForTypeProvider>
>> implicitStaticFeatures;
>>
>> it gets a Guice Provider that delivers objects whose type is assignable
>> to StaticMethodsFeatureForTypeProvider. Any subtype or the type itself
>> will do. It doesn't matter that StaticMethodsFeatureForTypeProvider is a
>> class and not an interface. The only difference is that we don't have to
>> bind a default implementation in this case, as the class itself is bound
>> by default. You can override that default binding using the same
>> mechanism as for an interface binding.
>
> As follows, you mean:
>
> public Class<? extends
> org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider>
> bindStaticMethodsFeatureForTypeProvider() {
> return no.hal.ecoretypes.x.StaticMethodsFeatureForTypeProvider.class;
> }
>
Exactly.
>>>> You need to *bind* a Guice Provider<> only if you want to change
>>>> Guice's
>>>> default instantiation strategy.
>>>
>>> I think the default strategy for a Provider<X> is to instantiate X,
>>> while I want it to instantiate a specific subclass.
>>
>> No, Guice creates an instance of the class that is bound to the specific
>> interface type. This binding is what you want to change. By default
>> instantiation strategy I meant calling the default constructor or the
>> one with only injected parameters.
>>
>>> Anyway, it works, so I'm happy!
>>>
>>> Hallvard
>>
>> Maybe it is a good idea to re-read the documentation on dependency
>> injection now, and get more familiar with Guice?
>
> I tend to read just enough to get things done. In this case, the
> strategy I used worked, but wasn't the cleanest solution. Over time,
> misunderstandings like this will be fewer, partly thanks to patient
> experts like you!
>
> Hallvard
No problem. I was just starting to get a bit impatient :-)
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
Goto Forum:
Current Time: Fri Apr 19 05:39:05 GMT 2024
Powered by FUDForum. Page generated in 0.02770 seconds |
] 
Search
Help
Register
Login
Home
