Community
Participate
Working Groups
I believe a big value add for the Eclipse 4.2 platform would be if we could use @Inject in plugin.xml based contributions. I believe this would require to scan the corresponding part for @Inject and adjustments in the wrapper classes. This is similar to Ralf Ebert suggestion in Bug 356511 would would not require a change in existing contribution class, e.g. View and would great an immediate benefit for adaptors.
Well do I get this right you'd like to use DI for stuff created through IConfiguration#createExecutableExtension(String)?
I like this one...wherever we actually instantiate the part I think we'd just need a specific 'inject' call, using the EclipseContext that we used to create the CompatibilityView...
Oleg, is there any way that an 'inject' call could interfere with a non-annotated class ?
@Eric: that would in my opinion a huge push for the e4 adaption. I just trained last week 10 developers in "classic" RCP and they were very excited about DI for their existing code.
(In reply to comment #4) > @Eric: that would in my opinion a huge push for the e4 adaption. I just trained > last week 10 developers in "classic" RCP and they were very excited about DI > for their existing code. the e4 bridge already allows DI in 3.x/4.x - in 3.x we bring up a new DI-Container and in 4.x we simply route through the original context created the EAP.
I see this as an easy way for us to pave the path towards folks currently working on 3.x components to start moving over to using the e4 approach of UI Model / DI. This is a *huge* win; people won't truly understand why we're on this path until they see the advantages themselves. In 4.x it should be very simple to implement, just call 'inject' on the part implementation object after it's instantiated. In order to allow the same code to run in both 3.x and 4.x they should supply the default value for any 'injectable' fields so that they run 'correctly' in 3.x where there's no injection. There's a different issue that may severely limit how useful this is though. Many (most) of the useful objects we inject are model elements or services that reference model elements. Components that want to use the same source for 3.x / 4.x are going to have requirements issues (i.e. no model in 3.x). But for folks that want to fork and move on up or starting fresh it's a great approach...
If an extension wants to use DI, why wouldn't they write an IExecutableExtensionFactory and specify that? That gives the user complete control over the object creation process. PW
In addition, we were going to look at not blindly injecting objects created from 3.x createExecutableExtension(*), so as not to interfere with other DI engines (as used by XText, for example). See bug 331746 and blockers. PW
@Paul: would be cool to have a default implementation of IExecutableExtensionFactory to do @Inject for "old" extension point contributions. Is there something available?
(In reply to comment #9) > @Paul: would be cool to have a default implementation of > IExecutableExtensionFactory to do @Inject for "old" extension point > contributions. Is there something available? You mean if we were to provide a utility IExecutableExtensionFactory so that it could be used to automatically @inject and editor or view part? Kind of an opt-in scenario? PW
@Paul: I like the idea of opt-in for this feature. If people register such an IExtensionFactory then @Inject would be used. Sounds great. Just for my understanding: This factory would create "only" the defined class via ContextInjectFactory.make(..) and return it, or would it also have to create the Composite and make sure that the right methods are called?
(In reply to comment #11) > @Paul: I like the idea of opt-in for this feature. If people register such an > IExtensionFactory then @Inject would be used. Sounds great. > > Just for my understanding: This factory would create "only" the defined class > via ContextInjectFactory.make(..) and return it, or would it also have to > create the Composite and make sure that the right methods are called? I'm not sure what opt-in means here. You opt-in by using the IExtensionFactory in your plugin.xml's class-attribute all the framework could provide is a default implementation for you to reference.
@Tom, the opt-in part from Paul was clear, of course this is done by using the IExtensionFactory in my extension point. My question was if the IExtensionFactory only needs to instantiates the class (which would be simple to implement) or if it has more responsibility. Looking at the code, of ExtensionFactory it looks like I just need to create and return an instance of the View class. Is that correct or are there more things to consider?
(In reply to comment #13) > My question was if the IExtensionFactory only needs to instantiates the class > (which would be simple to implement) or if it has more responsibility. My first thoughts would be that we would provide one in 4.2. org.eclipse.ui.DIPartExtensionFactory would use the same context to inject the part as we use to create the CompatibilityPart. Then clients would contribute views using: <view class="org.eclipse.ui.DIPartExtensionFactory:org.example.rcp.MyView" .../> The actual implementation would involve getting the correct context and using Bundle.loadClass(*) and CIF.make(*). PW
The e4 brigde does it by providing a base class you subclass DIViewPart and DIEditorPart, it then sets up a context hierarchy for Eclipse 3.x and simply reuses one the exisiting one in 4.x.
I personally moved to pure Eclipse 4 applications. Hence I'm closing this bug. If someone wants to work on this, please reopen.
Marking as WORKSFORME since no code changes were made. I don't want to give people the impression that this bug is FIXED.
Thanks Remy, I guess "Wontfix" is even better.
