Although creating a POJO can be an efficient way of creating simple classes, it can be limiting to have a concrete class definition scattered through the class definitions. It is a better design to use either an abstract class or an interface as the service type.
com.packtpub.e4.application
package, called IStringService
. Define the process()
method as abstract:public interface IStringService { public abstract String process(String string); }
Rainbow
class to refer to the IStringService
interface instead of the StringService
class:@Inject private IStringService stringService;
org.eclipse.e4.core.di.InjectionException: Unable to process "Rainbow.stringService": no actual value was found for the argument "IStringService".
StringService
is a @Creatable
instance, it doesn't look for subtypes of an interface by default. To inject an alternative type, modify the Activator
and add the following:public class Activator implements BundleActivator { public void start(BundleContext bundleContext) throws Exception{ Activator.context = bundleContext; InjectorFactory.getDefault(). addBinding(IStringService.class). implementedBy(StringService.class); } }
Using an interface for the service type is best practice, since it further decouples the use of the service with its implementation. In order for the dependency injection framework to provide an instance of an abstract type (whether an interface or abstract class, or even a concrete class without a @Creatable
annotation) a binding needs to be created for the injector.
The binding created above tells the InjectorFactory
to create an instance of StringService
when an IStringService
is required.
Although Eclipse 3.x parts can run in an Eclipse 4 IDE, to take advantage of the E4 model the code has to be implemented as a POJO such that it can be registered with a model. To fit an E4 POJO into an Eclipse 3.x IDE, the E4 bridge has to be used. Install the "Eclipse E4 Tools Bridge for 3.x" from the E4 update site, which provides the compatibility views.
Now, create a class called HelloView
which extends DIViewPart<Hello>
and passes the instance of Hello.class
to the superclass' constructor. Register the HelloView
in the plugin.xml
as would be the case with Eclipse 3.x views, and the part is now visible either as a standalone part in Eclipse 4 or as a wrapped view in Eclipse 3.x.
Q1. What is the application model, and what is it used for?
Q2. What is the different between a part and a view?
Q3. Are extension points still used in Eclipse 4?
Q4. How can Eclipse 4 parts be styled?
Q5. What is the Eclipse 4 context?
Q6. What annotations are used by Eclipse 4, and what are their purpose?
Q7. How are preferences accessed in Eclipse 4?
Q8. How can messages be sent and received on the event bus?
Q9. How is the selection accessed in Eclipse 4?