Home » Eclipse Projects » Rich Client Platform (RCP) » [e4] How to get ready ?
|
| Re: [e4] How to get ready ? [message #534960 is a reply to message #534946] |
Thu, 20 May 2010 19:29   |
 Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Am 20.05.10 20:15, schrieb Christophe Fondacci:
> Hello guys,
>
> I do not know much about e4 but started to read some docs about upcoming
> features. As a RCP app developer, I am REALLY interested in the service
> injection feature.
> So far, I need to handle service consumption in a custom way, most of
> the time relying on plugin singleton instance that gives me the proper
> service singleton I need. Not talking about the platform services but
> about "custom" services which a RCP app needs as well.
>
> So now I am wondering :
> - Will it be possible for us to take advantage of service injection to
> inject custom services ?
Yes. All services registered in OSGi-Service-Registry are a subject for
injection
> - Is there anything we can do right now in our developments to "prepare
> the future" ? I mean, is there some best practices which could reduce
> the migration efforts when e4 will be released ? This is always less
> work to prepare this now on fresh code than to refactor it after it has
> got old...
> Another question : will e4 migrate to Java 1.5 and will introduce the
> generics ? I ask this (but I guess the answer is no) because I can see
> in the e4 docs code like :
Some rules are:
* Don't inherit from things like ViewPart, EditorPart
* Don't references pure 3.x workbench services (e.g. ISelectionService)
=> Abstract them away in own services you delegate
If you want a concrete example on how to structure such a component you
can take a look at my ModelEditor which runs in:
* 3.x
* 4.0
* native e4
http://tomsondev.bestsolution.at/2010/05/17/a-week-at-e4-sha re-me-please/
Sources to it can be found in the
e4/org.eclipse.e4.tools/bundles/org.eclipse.e4.tools.emf*
>
> MWindow window = (MWindow)
> mwindow.getContext().get(MWindow.class.getName());
>
> And I can't wait being able to do this :
>
> MWindow window = mwindow.getContext().get(MWindow.class);
>
> thanks to generics: more compact, more readable, less writing.
We are using Java 5 generics so the you are able to write
MWindow window = mwindow.getContext().get(MWindow.class);
with the latest builds.
>
> I understand that there might be a big compatibility constraint for you
> Eclipse platform guyz....
>
> If anyone could lead me to some documentation on these topics it would
> be marvellous.
>
> Anyway thank you for all the great work you're doing on this release,
> Christophe
> http://www.nextep-softwares.com
>
Tom
|
|
|
| Re: [e4] How to get ready ? [message #534966 is a reply to message #534960] |
Thu, 20 May 2010 19:30 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Please use the e4 newsgroup for follow ups.
Tom
Am 20.05.10 21:29, schrieb Tom Schindl:
> Am 20.05.10 20:15, schrieb Christophe Fondacci:
>> Hello guys,
>>
>> I do not know much about e4 but started to read some docs about upcoming
>> features. As a RCP app developer, I am REALLY interested in the service
>> injection feature.
>> So far, I need to handle service consumption in a custom way, most of
>> the time relying on plugin singleton instance that gives me the proper
>> service singleton I need. Not talking about the platform services but
>> about "custom" services which a RCP app needs as well.
>>
>> So now I am wondering :
>> - Will it be possible for us to take advantage of service injection to
>> inject custom services ?
>
> Yes. All services registered in OSGi-Service-Registry are a subject for
> injection
>
>> - Is there anything we can do right now in our developments to "prepare
>> the future" ? I mean, is there some best practices which could reduce
>> the migration efforts when e4 will be released ? This is always less
>> work to prepare this now on fresh code than to refactor it after it has
>> got old...
>> Another question : will e4 migrate to Java 1.5 and will introduce the
>> generics ? I ask this (but I guess the answer is no) because I can see
>> in the e4 docs code like :
>
> Some rules are:
> * Don't inherit from things like ViewPart, EditorPart
> * Don't references pure 3.x workbench services (e.g. ISelectionService)
> => Abstract them away in own services you delegate
>
> If you want a concrete example on how to structure such a component you
> can take a look at my ModelEditor which runs in:
> * 3.x
> * 4.0
> * native e4
>
> http://tomsondev.bestsolution.at/2010/05/17/a-week-at-e4-sha re-me-please/
>
> Sources to it can be found in the
> e4/org.eclipse.e4.tools/bundles/org.eclipse.e4.tools.emf*
>
>
>>
>> MWindow window = (MWindow)
>> mwindow.getContext().get(MWindow.class.getName());
>>
>> And I can't wait being able to do this :
>>
>> MWindow window = mwindow.getContext().get(MWindow.class);
>>
>> thanks to generics: more compact, more readable, less writing.
>
> We are using Java 5 generics so the you are able to write
>
> MWindow window = mwindow.getContext().get(MWindow.class);
>
> with the latest builds.
>
>>
>> I understand that there might be a big compatibility constraint for you
>> Eclipse platform guyz....
>>
>> If anyone could lead me to some documentation on these topics it would
>> be marvellous.
>>
>> Anyway thank you for all the great work you're doing on this release,
>> Christophe
>> http://www.nextep-softwares.com
>>
>
> Tom
|
|
| | |
| Re: [e4] How to get ready ? [message #535168 is a reply to message #535166] |
Fri, 21 May 2010 13:17 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi,
What you want are OSGi (Declarative) Services?
Tom
Am 21.05.10 15:13, schrieb Christophe Fondacci:
> Thank you very much for your replies. It helped me understood how that
> will work.
>
> Regarding your last suggestion Paul, the org.eclipse.ui.services is
> indeed the kind of things I need to rely on. But this is UI-related
> stuff. A RCP product may need to declare non-UI services. At least this
> is my case.
>
> Actually, in my design I always try to seperate everything in business
> layer and UI layer. Even if the result is a RCP "graphical" application,
> I need to be able to extract the business part and make it run headless
> without any UI on top of it.
>
> This led me in the direction of always creating "business" services
> which literally do the work or fail and generally an UI companion
> service which could embed the processing in the UI (like by spawning the
> process in a UI job) or which could interact with the user to get
> information, handle UI-thread synchronization, or a combination of this.
>
> User-actions always rely on my UI services than delegating to one or
> several business services. Business services may only rely on other
> business services.
>
> I was looking for a way of registering these services so that they could
> be injected when migrating to e4. But it seems like everything is
> UI-stuff, at least in 3.x. I don't really like having 2 ways of
> accessing services (1 for the UI through service locators, 1 other for
> the business services) but maybe this is the best thing to do... Any
> best-practice on this (well mostly for business services) ?
>
> Hope I was clear enough...
> Thanks again for your explanations, it really helps.
>
> Christophe.
> http://www.nextep-softwares.com
>
>
>
|
|
| | | |
| Re: [e4] How to get ready ? [message #536644 is a reply to message #536526] |
Sat, 29 May 2010 08:35 |
Christophe Fondacci
Messages: 95
Registered: July 2009
Location: Paris |
Member |
|
|
Hello again,
I started wiring everything from OSGi DS.
Now I am getting into troubles at the "2 worlds" frontiers :
* I declare my DS components and it works great, injection works like a charm
* Now I need to "consume" one of my service in a Eclipse UI handler.
I found something which works but I am not satified with :
* Service A is declared as OSGi component
* I declare a UI service as a OSGi component which depend on service A (injection)
* I use the org.eclipse.ui.services to declare a service factory able to create my UI Service
* This factory relies on the OSGi BundleContext registry to lookup for the UI service and returns it.
I created a helper method for this :
public static <T> T getService(Class<T> serviceInterface) {
final BundleContext context = getDefault().getBundle().getBundleContext();
final ServiceReference ref = context.getServiceReference(serviceInterface.getName());
if (ref != null) {
Object o = context.getService(ref);
if (o != null && serviceInterface.isAssignableFrom(o.getClass())) {
return (T) o;
}
}
throw new ErrorException("Unable to locate requested service " + serviceInterface.getName());
}
The problem is that I would like injection everywhere up to my handler. Isn't there a way (I mean in 3.x) to inject a component in a eclipse ui service factory, in a ui handler, or even in the bundle activator so that I would not need to have a place where I manually lookup for services ?
Thank you,
Ah yes and another thing : each time I change my component XML file and restart my product, the change is not made. The only way to make it works is to remove from manifest, compile, run, stop, re-add to the manifest.
Weird ? Is there something I am missing ?
Christophe.
http://www.nextep-softwares.com
|
|
|
| Re: [e4] How to get ready ? [message #536649 is a reply to message #536644] |
Sat, 29 May 2010 09:26 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Am 29.05.10 10:35, schrieb Christophe Fondacci:
> Hello again,
> I started wiring everything from OSGi DS.
> Now I am getting into troubles at the "2 worlds" frontiers :
> * I declare my DS components and it works great, injection works like a
> charm
> * Now I need to "consume" one of my service in a Eclipse UI handler.
>
When you talk about UI-Handler are you talking about a CommandHandler or
an View/Editor Component?
> I found something which works but I am not satified with :
> * Service A is declared as OSGi component
> * I declare a UI service as a OSGi component which depend on service A
> (injection)
> * I use the org.eclipse.ui.services to declare a service factory able to
> create my UI Service
> * This factory relies on the OSGi BundleContext registry to lookup for
> the UI service and returns it.
>
> I created a helper method for this :
>
> public static <T> T getService(Class<T> serviceInterface) {
> final BundleContext context =
> getDefault().getBundle().getBundleContext();
> final ServiceReference ref =
> context.getServiceReference(serviceInterface.getName());
> if (ref != null) {
> Object o = context.getService(ref);
> if (o != null &&
> serviceInterface.isAssignableFrom(o.getClass())) {
> return (T) o;
> }
> }
> throw new ErrorException("Unable to locate requested service " +
> serviceInterface.getName());
> }
>
>
> The problem is that I would like injection everywhere up to my handler.
> Isn't there a way (I mean in 3.x) to inject a component in a eclipse ui
> service factory, in a ui handler, or even in the bundle activator so
> that I would not need to have a place where I manually lookup for
> services ?
As outlined one my answer you should not create your instances using DI
coming with e4. Then you get your services injected. If you are talking
about Command-Handlers the situation is quite similar but without
knowing wheter you currently talk about View/Editor Components or
Command-Handlers it might not make sense to go into detail with it.
For UI-Component injection you can take a look at my e4-ModelEditor
which does provide OSGi-Service injection to the View/Editor Component
level.
I hope I find some time to publish a minimal 3.x single sourcing example
on my blog http://tomsondev.bestsolution.at/ (simply subscribe to get
notified when I publish an article)
>
> Thank you,
> Ah yes and another thing : each time I change my component XML file and
> restart my product, the change is not made. The only way to make it
> works is to remove from manifest, compile, run, stop, re-add to the
> manifest.
> Weird ? Is there something I am missing ?
What does restart mean? Is it stop and start or really restart as known
in the Eclipse IDE? Anyways it is strange because normally you should
not even have to bring down your product at all but update only the
OSGi-Bundle and you'll get stuff uninjected/rejected :-)
Tom
|
|
| | |
| Re: [e4] How to get ready ? [message #536718 is a reply to message #536700] |
Sun, 30 May 2010 09:35 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Am 30.05.10 08:13, schrieb Christophe Fondacci:
> Hello,
>
> Thanks for your reply.
>
> I was talking about UI command handlers actually.
>
> Looked at your model editor and at your blog for your last post "Use
> D4-DI for 3.x" but I could not find any kind of "injection" at the UI
> layer. I saw that you retrieve the instance from the bundle context,
> which insipired the static method I detailed in my last post.
>
> But this is not literally "injection", as doing this should also implies
> monitoring the lifecycle of the services, writing some code, etc. If I
> understand well, I'll be able to work with pure injection in e4 (which
> also implies no direct creation of new instances to my point of view
> [coming from the spring world]), and make some kind of "glue code" in
> 3.x to be able to access DS components at some places.
>
> Am I right ? Or is it already possible to inject on the UI layer ? I was
> thinking that maybe the bundle activator, which is actually already
> managed by OSGi would be able to get injected components on it. This
> would solve my problems as I can inject all services that I need to
> access in the UI and then this activator would act as a bridge and I
> would not create any OSGi-dependant code to retrieve service from the
> bundle context...
yes in e4 the workbench acts as the injection container so the task in a
3.x world is to write such a container ontop of the 3.x API (the stuff
presented in my blog and my model editor is a first start) so that
people can consume it and don't have to worry about it.
I think what we would need is a DIViewPart, DIEditorPart and
DICommandHandler which acts as the injection container.
Tom
|
|
|
| Re: [e4] How to get ready ? [message #536720 is a reply to message #536718] |
Sun, 30 May 2010 09:47 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Am 30.05.10 11:35, schrieb Tom Schindl:
> Am 30.05.10 08:13, schrieb Christophe Fondacci:
>> Hello,
>>
>> Thanks for your reply.
>>
>> I was talking about UI command handlers actually.
>>
>> Looked at your model editor and at your blog for your last post "Use
>> D4-DI for 3.x" but I could not find any kind of "injection" at the UI
>> layer. I saw that you retrieve the instance from the bundle context,
>> which insipired the static method I detailed in my last post.
>>
>> But this is not literally "injection", as doing this should also implies
>> monitoring the lifecycle of the services, writing some code, etc. If I
>> understand well, I'll be able to work with pure injection in e4 (which
>> also implies no direct creation of new instances to my point of view
>> [coming from the spring world]), and make some kind of "glue code" in
>> 3.x to be able to access DS components at some places.
>>
>> Am I right ? Or is it already possible to inject on the UI layer ? I was
>> thinking that maybe the bundle activator, which is actually already
>> managed by OSGi would be able to get injected components on it. This
>> would solve my problems as I can inject all services that I need to
>> access in the UI and then this activator would act as a bridge and I
>> would not create any OSGi-dependant code to retrieve service from the
>> bundle context...
>
> yes in e4 the workbench acts as the injection container so the task in a
> 3.x world is to write such a container ontop of the 3.x API (the stuff
> presented in my blog and my model editor is a first start) so that
> people can consume it and don't have to worry about it.
>
> I think what we would need is a DIViewPart, DIEditorPart and
> DICommandHandler which acts as the injection container.
>
Once 4.0 is shipped I think about setting up a project providing those 3
things to people in an 3.x/4.0-compat world. So ideally in a few months
you don't have to worry about the glue code I presented in my blog but
create views and editor e.g. like this:
public class MyEditor extends DIEditor {
public MyEditor() {
super(MyComponent.class);
}
}
and DIEditor acts as the DI-Container just like the Workbench does in e4
world
Tom
|
|
| |
| Re: [e4] How to get ready ? [message #537863 is a reply to message #536718] |
Thu, 03 June 2010 21:51 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi Christophe,
Just to inform you on my progress on this. I just announced on the
e4-dev list that the first bits of a Forward Compat Layer are available.
The Forward Compat Layer allows at the moment to use the e4-Programming
model for Views and Editors.
The 3.x integration is done by subclassing DIEditor/DIViewPart like this
(example taken from the my Translator-Demo):
---------------8<---------------
public class TranslatorView extends DIViewPart<TranslatorComponent> {
public static final String ID =
"at.bestsolution.translate.view.views.TranslatorView";
public TranslatorView() {
super(TranslatorComponent.class);
}
/**
* Passing the focus request to the viewer's control.
*/
public void setFocus() {
getComponent().setFocus();
}
}
---------------8<---------------
TranslatorComponent is an POJO which gets injected all needed
informations available in the Editor-Context.
Tom
Am 30.05.10 11:35, schrieb Tom Schindl:
> Am 30.05.10 08:13, schrieb Christophe Fondacci:
>> Hello,
>>
>> Thanks for your reply.
>>
>> I was talking about UI command handlers actually.
>>
>> Looked at your model editor and at your blog for your last post "Use
>> D4-DI for 3.x" but I could not find any kind of "injection" at the UI
>> layer. I saw that you retrieve the instance from the bundle context,
>> which insipired the static method I detailed in my last post.
>>
>> But this is not literally "injection", as doing this should also implies
>> monitoring the lifecycle of the services, writing some code, etc. If I
>> understand well, I'll be able to work with pure injection in e4 (which
>> also implies no direct creation of new instances to my point of view
>> [coming from the spring world]), and make some kind of "glue code" in
>> 3.x to be able to access DS components at some places.
>>
>> Am I right ? Or is it already possible to inject on the UI layer ? I was
>> thinking that maybe the bundle activator, which is actually already
>> managed by OSGi would be able to get injected components on it. This
>> would solve my problems as I can inject all services that I need to
>> access in the UI and then this activator would act as a bridge and I
>> would not create any OSGi-dependant code to retrieve service from the
>> bundle context...
>
> yes in e4 the workbench acts as the injection container so the task in a
> 3.x world is to write such a container ontop of the 3.x API (the stuff
> presented in my blog and my model editor is a first start) so that
> people can consume it and don't have to worry about it.
>
> I think what we would need is a DIViewPart, DIEditorPart and
> DICommandHandler which acts as the injection container.
>
> Tom
|
|
| |
| Re: [e4] How to get ready ? [message #537991 is a reply to message #537886] |
Fri, 04 June 2010 12:36 |
|
Christophe Fondacci wrote:
> Nice, thank you Tom !
>
> Paul, regarding your answer, even if handlers won't be instantiated by
> the DI container, is there a chance that the :
>
> getSite().getService(MyService.class)
>
> ends up by looking in the DI container to return an appropriate
> implementation ? If so there would be no big deal of not having handlers
> injected since they could access services from the DI container in an
> abstract way.
In e4 the handler object itself is not injected when it is created,
because the context it is created in might not be the same as the
context it is executed in.
But the canExecute(*) and execute(*) method are run through the same DI
mechanism, just as a single-shot invoke instead of a permanent link.
ex: a handler that was to operate on a part wouldn't use @Inject like this:
@Inject private MPart part;
@Inject private EPartService partService;
Instead they would request the visible part from the context they are
executing in:
@Execute
public void execute(@Optional MPart part, EPartService partService)
That way they will always get the part service relevant to its execution
context.
In e4 with the compatibility layer,
getSite().getService(MyService.class) is simply a pass-through to
e4Context.get(key.getName()); In e4 with the compatibility layer, an
ExeuctionEvent IEvaluationContext is backed by an IEclipseContext as
well, so technically HandlerUtil.getVariable(event,
MyService.class.getName()) would return any applicable e4 service as
well. I'm not sure if our 3.x support that Tom is working on should
offer a DS source provider or not.
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
Goto Forum:
Current Time: Tue Apr 16 23:17:32 GMT 2024
Powered by FUDForum. Page generated in 0.34436 seconds |
] 
Search
Help
Register
Login
Home
