Home » Modeling » EMF » Transactional Editing Domain in an RCP
| Transactional Editing Domain in an RCP [message #416744] |
Fri, 15 February 2008 01:33  |
 Charles H Martin
Messages: 79
Registered: July 2009 |
Member |
|
|
This is a bit of a favor but I am hoping someone can lend a hand here
I would like to modify the current EMF.editor , generated for an RCP, so that is uses a shared, transactional editing domain instead of the default domain. (I have some very specific questions below if you want to jump down)
Of course, there is an example of this in the Transactions example source (EXTLibarayEditor), but the editor provided there is for use in a workspace, and not an RCP, so it contains some un-necessary additions such as the Workspace Synchronizer, the Undo Context, the automatic loading of resources, etc. I am fine if we could do this with just a single view (i.e a tree or table viewer), and not worrying about the Undo feature for now.
So what I am trying to do is sort through all the logic and determine what exactly is necessary just for the TransactionalEditingDomain itself and how some of the logic changes.
For example, in the generated EMF editor, there are 3 datastructures:
Collection<Resource> removedResources, changedResource, & savedResources
whereas in the EXTLibraryEditor has the additional movedResources
Consequently, many of the helper methods have changed, such as
isDirty()
handleDirtyConflict()
...
and it is just a little hard to deconvolute out what is really necessary for the Transactional behavior and what is necessary because the Editor is tied to the Workspace and is not a simple RCP.
Some initial questions:
(1) For a detailed example, in the normal EMF editor , the EditingDomain is given a BasicCommandStack.
But for a TransactionalEditingDomain, should one just obtain the TransactionCommandStack and downcast to the BasicCommandStack
or is there something subtle that needs to be considered here?
(2) Likewise, in the normal EMF editor, the adapterFactory is created, the ItemProviderAdapterFactories are added directly to this adpaterFactory, AND THEN the EditingDomain gets this "filled" adapterFactory. But in the TransactionalEditor, it seems that the editingDomain has a "default" ComposedAdapterFactory, and the ItemProviderAdapterFactories are given to the
TransactionalAdapterFactoryContentProvider as
selectionViewer.setContentProvider(new TransactionalAdapterFactoryContentProvider((TransactionalEdi tingDomain) getEditingDomain(), adapterFactory));
So this is a bit confusing at first glance, and I have to think hard about what exactly the editingDomain needs and how it is coupled to the adapterFactory ?
(3) This is also confusing because the TransactionalEditingDomain in the examples is a WorkspaceEditingDomainFactory
I greatly appreciate any help sorting through this and I hope the answer will be useful to other people trying to understand and use the Transactional features of EMF for their RCPs
|
|
|
| Re: Transactional Editing Domain in an RCP [message #416750 is a reply to message #416744] |
Fri, 15 February 2008 20:46  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Charles,
See some comments in-line, below.
HTH,
Christian
Charles Martin wrote:
> This is a bit of a favor but I am hoping someone can lend a hand here
>
> I would like to modify the current EMF.editor , generated for an RCP, so
> that is uses a shared, transactional editing domain instead of the default
> domain. (I have some very specific questions below if you want to jump
> down)
>
> Of course, there is an example of this in the Transactions example source
> (EXTLibarayEditor), but the editor provided there is for use in a
> workspace, and not an RCP, so it contains some un-necessary additions such
> as the Workspace Synchronizer, the Undo Context, the automatic loading of
> resources, etc. I am fine if we could do this with just a single view
> (i.e a tree or table viewer), and not worrying about the Undo feature for
> now.
Well, some of these additions might be welcome in an RCP app, too. The
operation-history integration, for example, would be as valuable in an RCP
as in an IDE.
The only API in the org.eclipse.emf.workspace.* plug-ins that is about the
workspace is the WorkspaceSynchronizer.
> So what I am trying to do is sort through all the logic and determine what
> exactly is necessary just for the TransactionalEditingDomain itself and
> how some of the logic changes.
>
> For example, in the generated EMF editor, there are 3 datastructures:
>
> Collection<Resource> removedResources, changedResource, & savedResources
>
> whereas in the EXTLibraryEditor has the additional movedResources
Yes, this is because the WorkspaceSynchronizer is capable of detecting
resource moves, which is handy because otherwise interpreting a move as a
delete and an add would be disruptive to the editor (it would need to
reload from disk, which shouldn't be necessary).
> Consequently, many of the helper methods have changed, such as
>
> isDirty()
> handleDirtyConflict()
> ..
>
> and it is just a little hard to deconvolute out what is really necessary
> for the Transactional behavior and what is necessary because the Editor is
> tied to the Workspace and is not a simple RCP.
>
> Some initial questions:
>
> (1) For a detailed example, in the normal EMF editor , the EditingDomain
> is given a BasicCommandStack. But for a TransactionalEditingDomain, should
> one just obtain the TransactionCommandStack and downcast to the
> BasicCommandStack or is there something subtle that needs to be considered
> here?
I'm not sure what you're getting at, here. The default implementation of
the TransactionalCommandStack is a kind of BasicCommandStack, so usually
this cast is safe. But why be concerned with whether it is a
BasicCommandStack?
> (2) Likewise, in the normal EMF editor, the adapterFactory is created, the
> ItemProviderAdapterFactories are added directly to this adpaterFactory,
> AND THEN the EditingDomain gets this "filled" adapterFactory. But in the
> TransactionalEditor, it seems that the editingDomain has a "default"
> ComposedAdapterFactory, and the ItemProviderAdapterFactories are given to
> the TransactionalAdapterFactoryContentProvider as
>
> selectionViewer.setContentProvider(new
> TransactionalAdapterFactoryContentProvider((TransactionalEdi tingDomain)
> getEditingDomain(), adapterFactory));
Well, the choice to use the ComposedAdapterFactory was more or less
arbitrary. There's no reason to change this from what EMF would generate
for you. OTOH, the usage of this adapter factory should be via the
transactional provider wrappers such as the content-provider, above. This
is important to ensure that access to the resource-set contents being
edited is encapsulated in the appropriate transactions.
> So this is a bit confusing at first glance, and I have to think hard about
> what exactly the editingDomain needs and how it is coupled to the
> adapterFactory ?
The adapter factory, as such, has nothing to do with transactions. In fact,
the eAdapters() list on EObjects is not a feature (storing model content)
so it is not subject to the transaction protocol.
It is only providers such as the TransactionalAdapterFactoryContentProvider
that need to know what editing domain they are working in so that they can
create transactions as needed to access your data. The fact that they also
use adapter-factories is orthogonal.
> (3) This is also confusing because the TransactionalEditingDomain in the
> examples is a WorkspaceEditingDomainFactory
It is *created by* a WorkspaceEditingDomainFactory. The only practical
difference is that its command-stack is an IWorkspaceCommandStack,
delegating to the IOperationHistory, instead of a regular
TransactionalCommandStack. Otherwise, the actual editing domain
implementation is the same.
> I greatly appreciate any help sorting through this and I hope the answer
> will be useful to other people trying to understand and use the
> Transactional features of EMF for their RCPs
I hope my responses were useful!
|
|
|
| Re: Transactional Editing Domain in an RCP [message #416751 is a reply to message #416750] |
Fri, 15 February 2008 23:07 |
Charles H Martin
Messages: 79
Registered: July 2009 |
Member |
|
|
Hi
Thanks for the detailed feedback. I may have some more detailed questions, but, first, let me a ask a couple of other things about the EMF Transaction usage:
(1) I have case with a view that needs to read an EMF model and run a very long calculation (i.e. 30 seconds). Would it make sense to have the view hold a 30 sec readLock? Or, more specifically, if the view yields the readLock to the editor (i.e so the user can pan down a table), will the editor then yield the readLock back to the view so the calculation can continue?
(2) A question about the design of the framework...is there ever a case you have encountered when you would like to know when a readLock or a writeLock has been aquired?
For example, I would like know writeLock or a readLock is acquired so I can display some visual cue to the user (i.e a lock icon overlay), or deactivate a button. In my app,, the user may press a Load button, and while the data is being fetched, the "chart" button might be deactivated.
Is this a reasonable solution to you, or do you think it would it just be better to maintain my own state (i.e. similar to tracking that the editor is "dirty") or fire my own event (i.e. loadStartedEvent, loadFinishedEvent). Or perhaps there is another common design
(3) Could you clarify a bit how the operation-history integration, could be utilized in an RCP ?
Thanks again
Charles
|
|
|
| Re: Transactional Editing Domain in an RCP [message #416881 is a reply to message #416751] |
Tue, 19 February 2008 15:22 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
hi, Charles,
Find some comments in-line.
HTH,
Christian
Charles Martin wrote:
> Hi
>
> Thanks for the detailed feedback. I may have some more detailed
> questions, but, first, let me a ask a couple of other things about the
> EMF Transaction usage:
>
> (1) I have case with a view that needs to read an EMF model and run a
> very long calculation (i.e. 30 seconds). Would it make sense to have
> the view hold a 30 sec readLock? Or, more specifically, if the view
> yields the readLock to the editor (i.e so the user can pan down a
> table), will the editor then yield the readLock back to the view so the
> calculation can continue?
Yes. Multiple long-running transactions can yield to one another in
round-robin fashion using the TransactionalEditingDomain::yield() API.
Currently, yielding is fair: the longest-waiting thread is the next to be
resumed from its yield (the API does not implement transaction priority).
So, frequent yielding is probably good for liveness.
> (2) A question about the design of the framework...is there ever a case
> you have encountered when you would like to know when a readLock or a
> writeLock has been aquired?
None that *I* have yet encountered, but there is an outstanding enhancement
request for more transaction lifecycle notifications:
https://bugs.eclipse.org/145877
> For example, I would like know writeLock or a readLock is acquired so I
> can display some visual cue to the user (i.e a lock icon overlay), or
> deactivate a button. In my app,, the user may press a Load button, and
> while the data is being fetched, the "chart" button might be deactivated.
Sounds like a reasonable thing to do. I suppose, though, that you could
also just rely on the "User Operation Blocked" dialog that will inevitably
show up when the user initiates some action that requires a read/write
transaction while some long-running read(s) is/are in progress.
> Is this a reasonable solution to you, or do you think it would it just be
> better to maintain my own state (i.e. similar to tracking that the editor
> is "dirty") or fire my own event (i.e. loadStartedEvent,
> loadFinishedEvent). Or perhaps there is another common design
Reasonable, yes. However, I expect that implementing your own busy state
will give your application more control. After all, your editor will know
what the purpose of any given transaction is when it initiates it, and so
can make more informed decisions about UI enablement. Otherwise, relying
on listeners such as would be provided by 145877 would result in all
transactions of any duration or purpose causing your UI to be updated.
They could be tagged with options defined by your application, but then
that's tantamount implementing your own busy state, anyway. :-)
> (3) Could you clarify a bit how the operation-history integration, could
> be utilized in an RCP ?
I'm not sure what there is to elaborate. It works much the same as in an
IDE. The workbench may not be available to provide the shared operation
history, but the DefaultOperationHistoryFactory would still provide this.
AFAIK, the IOperationHistory API has no IDE dependencies; it's a
general-purpose implementation of the Command pattern.
> Thanks again
>
> Charles
|
|
|
Goto Forum:
Current Time: Thu Apr 25 10:23:00 GMT 2024
Powered by FUDForum. Page generated in 0.03350 seconds |
] 
Search
Help
Register
Login
Home
