Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMFStore] access to EditingDomain in EMFStore
| |
| Re: [EMFStore] access to EditingDomain in EMFStore [message #1129646 is a reply to message #1129068] |
Tue, 08 October 2013 21:16   |
 Scott Dybiec
Messages: 148
Registered: July 2009 |
Senior Member |
|
|
Maximilian,
The compliments are well deserved.
I have specialized the standard EMF CommandStack to allow for listening
on dirty state changes. If I understand your comment below, in EMFStore
1.1 I'll be able to replace the CommandStack with my own specialized
version. Do I have that right?
I use this MonitoredCommandStack as a trigger for an auto-save feature
for standard EMF XMI resources. With EMFStore there seems to be an
auto-save feature already built-in, but I'm not sure how I should be
using it.
Scott
On 10/8/2013 4:53 AM, Maximilian Koegel wrote:
> Hi Scott,
>
> thank you for your compliments! ;)
>>
>> EMFStore's own persistent store and ModelElements seems to be a very
>> different persistence model than the Resource-based XMI and CDO
>> persistence engines. And I'm guessing that it's use of the internal
>> EditingDomain is different as well.
>>
>> What recommendations do you have surfacing do/undo and determining
>> whether model instance is dirty? Should I use the EditingDomain
>> available in the ESWorkspaceImpl?
> Yes, you should use this EditingDomain and run your commands on the
> command stack of this editing domain. The editing domain will be
> attached to any of you domain objects and can be retrieved with
> AdapterFactoryEditingDomain.getEditingDomainFor(). You can use the
> undo/redo capabilities of the command stack as usual.
> To avoid manually implementing undo for custom commands (e.g. non EMF
> Commands), there is a way to use the recorded changes of EMFStore to
> implement undo, but it requires replacing the default EMFStore command
> stack. There are EMFStore users that are using EMFStore in this way.
> With EMFStore 1.1 it will be possible to have one command stack per
> project, in case you need that.
> To determine if there are pending changes on a project you can use
> hasUncomittedChanges(), which will return true if you changed something
> locally without committing the changes to a server.
> Let me know if I can provide more help!
>
> Cheers,
> Maximilian
>
>>
>> Scott
>>
>
>
|
|
|
| Re: [EMFStore] access to EditingDomain in EMFStore [message #1130233 is a reply to message #1129646] |
Wed, 09 October 2013 10:44 |
Maximilian Koegel
Messages: 253
Registered: July 2009 |
Senior Member |
|
|
Hi Scott,
by implementing the interface ESEditingDomainProvider and registering it
via the org.eclipse.emf.emfstore.client.editingDomainProvider extension
point in the org.eclipse.emf.emfstore.client plugin, you can already
replace the editing domain including its command stack. Please note that
your command stack must implement EMFStoreCommandStack, which is
currently an internal interface unfortunately, see this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=419009
An example for replacing the editing domain and command stack is the
plugin org.eclipse.emf.emfstore.client.transaction, it replaced the
editing domain with a transaction editing domain and a transactional
command stack.
The auto-save feature is not exposed in the (external) API and we chose
to remove it also internally since it can cause performance problems for
larger models. (It is off by default.)
Hope this helps!
Cheers,
Maximilian
Am 08.10.2013 23:16, schrieb Scott Dybiec:
> Maximilian,
>
> The compliments are well deserved.
>
> I have specialized the standard EMF CommandStack to allow for listening
> on dirty state changes. If I understand your comment below, in EMFStore
> 1.1 I'll be able to replace the CommandStack with my own specialized
> version. Do I have that right?
>
> I use this MonitoredCommandStack as a trigger for an auto-save feature
> for standard EMF XMI resources. With EMFStore there seems to be an
> auto-save feature already built-in, but I'm not sure how I should be
> using it.
>
> Scott
>
> On 10/8/2013 4:53 AM, Maximilian Koegel wrote:
>> Hi Scott,
>>
>> thank you for your compliments! ;)
>>>
>>> EMFStore's own persistent store and ModelElements seems to be a very
>>> different persistence model than the Resource-based XMI and CDO
>>> persistence engines. And I'm guessing that it's use of the internal
>>> EditingDomain is different as well.
>>>
>>> What recommendations do you have surfacing do/undo and determining
>>> whether model instance is dirty? Should I use the EditingDomain
>>> available in the ESWorkspaceImpl?
>> Yes, you should use this EditingDomain and run your commands on the
>> command stack of this editing domain. The editing domain will be
>> attached to any of you domain objects and can be retrieved with
>> AdapterFactoryEditingDomain.getEditingDomainFor(). You can use the
>> undo/redo capabilities of the command stack as usual.
>> To avoid manually implementing undo for custom commands (e.g. non EMF
>> Commands), there is a way to use the recorded changes of EMFStore to
>> implement undo, but it requires replacing the default EMFStore command
>> stack. There are EMFStore users that are using EMFStore in this way.
>> With EMFStore 1.1 it will be possible to have one command stack per
>> project, in case you need that.
>> To determine if there are pending changes on a project you can use
>> hasUncomittedChanges(), which will return true if you changed something
>> locally without committing the changes to a server.
>> Let me know if I can provide more help!
>>
>> Cheers,
>> Maximilian
>>
>>>
>>> Scott
>>>
>>
>>
>
--
Maximilian Kögel
Get Professional Eclipse Support: http://eclipsesource.com/munich
|
|
|
| Re: [EMFStore] access to EditingDomain in EMFStore [message #1137299 is a reply to message #1130233] |
Mon, 14 October 2013 11:45 |
Scott Dybiec
Messages: 148
Registered: July 2009 |
Senior Member |
|
|
Thanks, Maximilian. That worked.
I also have a related question.
I'd like to be able to store and later find specific model elements
stored in EMFStore by a name or tag that my application generates. Today
my application stores EMF files in a workspace project. If I were to add
these as model elements to EMFStore, then I think the only way to find
them again is by the EMFStore-assigned model element ID.
If assigning an application-defined name is not possible, then is it OK
to use the ResourceSet within the EMFStore EditingDomain to create EMF
Resources? Will proxies be resolved between these newly created
resources and those managed as model elements within EMFStore?
$cott
On 10/9/2013 6:44 AM, Maximilian Koegel wrote:
> Hi Scott,
>
> by implementing the interface ESEditingDomainProvider and registering it
> via the org.eclipse.emf.emfstore.client.editingDomainProvider extension
> point in the org.eclipse.emf.emfstore.client plugin, you can already
> replace the editing domain including its command stack. Please note that
> your command stack must implement EMFStoreCommandStack, which is
> currently an internal interface unfortunately, see this bug:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=419009
> An example for replacing the editing domain and command stack is the
> plugin org.eclipse.emf.emfstore.client.transaction, it replaced the
> editing domain with a transaction editing domain and a transactional
> command stack.
> The auto-save feature is not exposed in the (external) API and we chose
> to remove it also internally since it can cause performance problems for
> larger models. (It is off by default.)
> Hope this helps!
>
> Cheers,
> Maximilian
>
> Am 08.10.2013 23:16, schrieb Scott Dybiec:
>> Maximilian,
>>
>> The compliments are well deserved.
>>
>> I have specialized the standard EMF CommandStack to allow for listening
>> on dirty state changes. If I understand your comment below, in EMFStore
>> 1.1 I'll be able to replace the CommandStack with my own specialized
>> version. Do I have that right?
>>
>> I use this MonitoredCommandStack as a trigger for an auto-save feature
>> for standard EMF XMI resources. With EMFStore there seems to be an
>> auto-save feature already built-in, but I'm not sure how I should be
>> using it.
>>
>> Scott
>>
>> On 10/8/2013 4:53 AM, Maximilian Koegel wrote:
>>> Hi Scott,
>>>
>>> thank you for your compliments! ;)
>>>>
>>>> EMFStore's own persistent store and ModelElements seems to be a very
>>>> different persistence model than the Resource-based XMI and CDO
>>>> persistence engines. And I'm guessing that it's use of the internal
>>>> EditingDomain is different as well.
>>>>
>>>> What recommendations do you have surfacing do/undo and determining
>>>> whether model instance is dirty? Should I use the EditingDomain
>>>> available in the ESWorkspaceImpl?
>>> Yes, you should use this EditingDomain and run your commands on the
>>> command stack of this editing domain. The editing domain will be
>>> attached to any of you domain objects and can be retrieved with
>>> AdapterFactoryEditingDomain.getEditingDomainFor(). You can use the
>>> undo/redo capabilities of the command stack as usual.
>>> To avoid manually implementing undo for custom commands (e.g. non EMF
>>> Commands), there is a way to use the recorded changes of EMFStore to
>>> implement undo, but it requires replacing the default EMFStore command
>>> stack. There are EMFStore users that are using EMFStore in this way.
>>> With EMFStore 1.1 it will be possible to have one command stack per
>>> project, in case you need that.
>>> To determine if there are pending changes on a project you can use
>>> hasUncomittedChanges(), which will return true if you changed something
>>> locally without committing the changes to a server.
>>> Let me know if I can provide more help!
>>>
>>> Cheers,
>>> Maximilian
>>>
>>>>
>>>> Scott
>>>>
>>>
>>>
>>
>
>
|
|
|
| Re: [EMFStore] access to EditingDomain in EMFStore [message #1137735 is a reply to message #1137299] |
Mon, 14 October 2013 17:58 |
Maximilian Koegel
Messages: 253
Registered: July 2009 |
Senior Member |
|
|
Hi Scott,
I am not sure if fully understand what you want to do but I will try to
provide an answer...;)
You can influence the IDs (they are essentially Strings) assigned to
model elements in two ways. For both ways it is essential that the IDs
you assign are really unique within a project, otherwise behavior is
unspecified.
First you can register an ESModelElementIdGenerator at the extension
point "org.eclipse.emf.emfstore.common.model.modelelementIdGenerator".
Thereby you can assign IDs to newly created elements.
Second you can pre-assign an ID to a selected EObject BEFORE adding it
to a project (or the containment tree of a project). This is currently
internal API only so you need to cast ESLocalProject to
ESLocalProjectImpl and call the method toInternalAPI(). It will return a
ProjectSpace which is an internal API type that gives you full access to
all EMFStore internals. On ProjectSpace you can call
getProject().allocateModelElementIds() to pre-allocate IDs for new EObjects.
BTW: This is a common pattern to get to the internal API of a class X.
Cast to XImpl and call toInternalAPI(). We intend to add more methods to
the API over time, so let me know if you need something of the internal API.
Hope this works for you!
Cheers,
Maximilian
Am 14.10.2013 13:45, schrieb scott@xxxxxxxx:
> Thanks, Maximilian. That worked.
>
> I also have a related question.
>
> I'd like to be able to store and later find specific model elements
> stored in EMFStore by a name or tag that my application generates. Today
> my application stores EMF files in a workspace project. If I were to add
> these as model elements to EMFStore, then I think the only way to find
> them again is by the EMFStore-assigned model element ID.
>
> If assigning an application-defined name is not possible, then is it OK
> to use the ResourceSet within the EMFStore EditingDomain to create EMF
> Resources? Will proxies be resolved between these newly created
> resources and those managed as model elements within EMFStore?
>
> $cott
>
> On 10/9/2013 6:44 AM, Maximilian Koegel wrote:
>> Hi Scott,
>>
>> by implementing the interface ESEditingDomainProvider and registering it
>> via the org.eclipse.emf.emfstore.client.editingDomainProvider extension
>> point in the org.eclipse.emf.emfstore.client plugin, you can already
>> replace the editing domain including its command stack. Please note that
>> your command stack must implement EMFStoreCommandStack, which is
>> currently an internal interface unfortunately, see this bug:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=419009
>> An example for replacing the editing domain and command stack is the
>> plugin org.eclipse.emf.emfstore.client.transaction, it replaced the
>> editing domain with a transaction editing domain and a transactional
>> command stack.
>> The auto-save feature is not exposed in the (external) API and we chose
>> to remove it also internally since it can cause performance problems for
>> larger models. (It is off by default.)
>> Hope this helps!
>>
>> Cheers,
>> Maximilian
>>
>> Am 08.10.2013 23:16, schrieb Scott Dybiec:
>>> Maximilian,
>>>
>>> The compliments are well deserved.
>>>
>>> I have specialized the standard EMF CommandStack to allow for listening
>>> on dirty state changes. If I understand your comment below, in EMFStore
>>> 1.1 I'll be able to replace the CommandStack with my own specialized
>>> version. Do I have that right?
>>>
>>> I use this MonitoredCommandStack as a trigger for an auto-save feature
>>> for standard EMF XMI resources. With EMFStore there seems to be an
>>> auto-save feature already built-in, but I'm not sure how I should be
>>> using it.
>>>
>>> Scott
>>>
>>> On 10/8/2013 4:53 AM, Maximilian Koegel wrote:
>>>> Hi Scott,
>>>>
>>>> thank you for your compliments! ;)
>>>>>
>>>>> EMFStore's own persistent store and ModelElements seems to be a very
>>>>> different persistence model than the Resource-based XMI and CDO
>>>>> persistence engines. And I'm guessing that it's use of the internal
>>>>> EditingDomain is different as well.
>>>>>
>>>>> What recommendations do you have surfacing do/undo and determining
>>>>> whether model instance is dirty? Should I use the EditingDomain
>>>>> available in the ESWorkspaceImpl?
>>>> Yes, you should use this EditingDomain and run your commands on the
>>>> command stack of this editing domain. The editing domain will be
>>>> attached to any of you domain objects and can be retrieved with
>>>> AdapterFactoryEditingDomain.getEditingDomainFor(). You can use the
>>>> undo/redo capabilities of the command stack as usual.
>>>> To avoid manually implementing undo for custom commands (e.g. non EMF
>>>> Commands), there is a way to use the recorded changes of EMFStore to
>>>> implement undo, but it requires replacing the default EMFStore command
>>>> stack. There are EMFStore users that are using EMFStore in this way.
>>>> With EMFStore 1.1 it will be possible to have one command stack per
>>>> project, in case you need that.
>>>> To determine if there are pending changes on a project you can use
>>>> hasUncomittedChanges(), which will return true if you changed something
>>>> locally without committing the changes to a server.
>>>> Let me know if I can provide more help!
>>>>
>>>> Cheers,
>>>> Maximilian
>>>>
>>>>>
>>>>> Scott
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Maximilian Kögel
Get Professional Eclipse Support: http://eclipsesource.com/munich
|
|
|
Goto Forum:
Current Time: Thu Apr 25 12:48:56 GMT 2024
Powered by FUDForum. Page generated in 0.03070 seconds |
] 
Search
Help
Register
Login
Home
