Hi,
First: THANKS AGAIN!
I've managed to implement solution 2) and it looks pretty nice :D.
Second: I'll just sum up things a bit to be sure to get in the right
direction for the feature
I don't understand your first solution using fragments. But as this looks
as the least flexible one, it's not our preferred solution.
Solution 1) seems to be the "OSGi" way of handling things (if I got it
right). Its pretty flexible but enforces the consuming plugin
to also go the "OSGi" way and request the service properly.
As said above solution 2) seems to be the most flexible and works pretty
good. The problem with our application (not your solution) is
that we went a completely wrong way from beginning of the project. None of
our service interface plugins are implemented as part of
the application model. As we could not get DI working properly we used
static factory methods to retrieve instances (now its clear why
DI didn't work as expected).
So, what we would do now (to get things right):
1. Change service plugins (those just hold a generic service, e. g.
ContactService) to be an addon for application (this ensures that
service classes could be injected to the context using the first
approach "@PostConstruct").
2. Change storage plugins (just the implementation, e. g.
MySqlContactStorage) to OSGi services like solution 2. of your last email.
(this way
we can easily change the used backend)
3. We then can request a storage implementation from the generic service
class using DI and also use the service in the user interface using DI.
Last question is then how to dynamically enable / disable an installed
backend. But that will be asked (if I don't find a solution myself) in
another email to not mix up topics..
Last:
One last time: thanks!
Ben
2013/5/9 Paul Webster <[email protected]>
> There are a couple of ways to do that. If you don't specify it in your
> base model, you can have a fragment add your addon to the model.
>
> But for providing services that are accessible from the context, you have
> 2 other options:
>
> 1) simply have the implementation register an OSGi service. By default
> you can pick those up through the IEclipseContext. you'll get a different
> implementation depending on which bundles is available.
>
> 2) use DS to add a service as an IContextFunction, similar to
> http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/bundles/org.eclipse.e4.ui.workbench.swt/OSGI-INF/statusreporter.xml
> That service can provide a ContextFunction that instantiates your services
> as needed.
>
>
> PW
>
> --
> Paul Webster
> Hi floor. Make me a sammich! - GIR
>
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
