|Re: Using the EMF Client Platform [message #1082940 is a reply to message #1082240]
||Fri, 09 August 2013 08:28
| Jonas Helming
Registered: July 2009
There are two ways you can go:
1. If you want to use the core of ECP (i.e. the provider, the
repositories, projects. observerbus, etc.) in the background and just
want to provide another UI to it, you can do so by using the API. This
way you can things such as projects from the user. BDW, many things such
as the EMFStore are exchangeable in the existing UI. If none of the
existing providers (CDO, EMFStore or File) fits your needs, you can
implement an own one, as Erdal stated.
2. You can only use the editor. You implement your own backend and own
views to open the editor. This possibility is explicitly supported. It
is not part of the official API, yet, that is planed for 1.1. However, I
would recommend to already use it. The API might change a bit until 1.1,
but this only affects a few methods and should not require much
migration efforts. To open an editor, you can either use:
modelElementContext) This allows you to render the content of the editor
into any existing view (in case of SWT a composite)
b) MEEditorInput input = new MEEditorInput(new YourEditorContext(),
This will open a view in the workbench containing an editor.
The editor basically only requires an EObject to be opened.
Additionally, it requires some methods to be implemented, which allow
the editor to talk to the layer managing all EObjects. As an example,
the editor needs an EditingDomain.
In the default case, if you use the ecp core, the editor calls the
project, from which a EObject was opened. However, all necessary calls
are abstracted in an interface called ECPControlContext. If you don't
use the ecp core layer, but want to adapt the editor to your own backend
(or in-memory EObjects), you need to provide an own implementation of
ECPControlContext. You can look at ECPControlContextImpl, how the
methods are implemented for ecp core.
Some of the methods are only needed, if references are rendered in the
editor. If you only display EAttributes, you can leaves these
unimplemented. We plan to move these methods out of the
The ECPControlContext allows to render the inner component of the
editor. For the view, an ECPEditorContext is required, which is a
sub-interface of ECPControlContext. It adds the possibility to dispose
the context. This is required to close the views showing elements, if
they are deleted (in case of the ecp core from a project).
If you are unsure, which way to go, you can ping me on Skype:
"JonasHelming". If you describe me your requirements a little more in
detail, I can more easily tell you, which way is better for you.
Am 08.08.2013 11:35, schrieb Phillip Drew:
> Sorry my response has taken so long, and thanks for the prompt reply.
> That does help with how to create an application that uses the ECP,
> however I'm still a bit lost regarding how to utilise individual
> I want to insulate users from the EMF Store repository, and the idea of
> 'projects' in the Model Explorer. I assume that level of customisation
> isn't possible so I'll have to just use the editors? How can I just use
> the ECP editors and how can I easily open an editor on a model element?
Powered by FUDForum
. Page generated in 0.01838 seconds