Home » Modeling » EMF » Undo/Redo in EMF based RCP application
| | |
| Re: Undo/Redo in EMF based RCP application [message #425811 is a reply to message #425808] |
Tue, 09 December 2008 08:52   |
|
This is a multi-part message in MIME format.
--------------040501040008050307060401
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
It's really long ago that I did it but it's possible.
Have a look at createPages() in the editor:
| Tree tree = *new *Tree(getContainer(), SWT.MULTI);
selectionViewer = *new *TreeViewer(tree);
setCurrentViewer(selectionViewer);
selectionViewer.setContentProvider(*new *AdapterFactoryContentProvider(adapterFactory));
selectionViewer.setLabelProvider(*new *CDOLabelProvider(adapterFactory, view, selectionViewer));
selectionViewer.setInput(viewerInput);
*new *AdapterFactoryTreeEditor(selectionViewer.getTree(), adapterFactory);
createContextMenuFor(selectionViewer);|
I think this code is not strictly EditorPart related so it should work
more or less in a ViewPart, too.
Cheers
/Eike
----
http://thegordian.blogspot.com
Christian Hauser schrieb:
> Hi JF
>
> Thank you for your reply. I've seen that
> EditingDomainActioBarContributor offers me undo/redo actions. However,
> I'm using a view, not an editor. Is it possible to use the
> EditingDomainActionBarContributor within a view, too?
>
> Christian
>
>
> JF wrote:
>> Hi,
>> Assuming you have tried the library example (e.g.
>> http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.emf.doc/references/overview/EMF.html
>> and go all the way to generating and runnning an editor), I assume
>> you want to know how to override undo/redo and where to look.
>>
>> The generated editor will have generated an action bar contributor,
>> e.g. LibraryActionBarContributor which will inherit from
>> EditingDomainActionBarContributor which defines the Undo/Redo actions.
>> These simply call undo/redo on the editor's command stack. Undo/redo
>> on the editor's command stack simply call undo/redo on the command at
>> the top of the stack.
>> So if you were looking for an action contribution you won't find it
>> (I think - Ed will correct me) you need to override the command
>> creation for the ItemProvider in the .edit plugin generated for your
>> model, or override EditingDomainActionBarContributor in your
>> generated editor's actionbar contributor.
>>
>> Hope this helps, and I have caught your intent...
>>
--------------040501040008050307060401
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
It's really long ago that I did it but it's possible.<br>
Have a look at createPages() in the editor:<br>
<br>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = -->
<!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff">
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: Undo/Redo in EMF based RCP application [message #425828 is a reply to message #425814] |
Tue, 09 December 2008 14:12 |
 Christian Hauser
Messages: 189
Registered: July 2009 |
Senior Member |
|
|
Thank you JF and Eike for your help
I have a CommandStackListener registered (CommandStackListenerImpl).
However, the method commandStackChanged() is never called. (see code
snippet below)
resourceSet = new ResourceSetImpl();
// Register the appropriate resource factory to handle all file
extensions.
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put(
Resource.Factory.Registry.DEFAULT_EXTENSION, new
XMIResourceFactoryImpl());
// Register the package to ensure it is available during loading.
resourceSet.getPackageRegistry().put(ModelPackage.eNS_URI,
ModelPackage.eINSTANCE);
// Create an adapter factory that yields item providers.
ComposedAdapterFactory adapterFactory = new ComposedAdapterFactory(
ComposedAdapterFactory.Descriptor.Registry.INSTANCE);
adapterFactory.addAdapterFactory(new
ResourceItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new
ModelItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new
ReflectiveItemProviderAdapterFactory());
// Create the command stack that will notify this editor as
commands are executed.
BasicCommandStack commandStack = new BasicCommandStack();
// Create the editing domain with a special command stack.
editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
commandStack, resourceSet);
editingDomain.getCommandStack().addCommandStackListener(new
CommandStackListenerImpl());
If someone could enlighten me on why my CommandStackListener is not
working, I'd be very happy.
Thanks in advance,
Christian
JF wrote:
> Although you can re-use the EMF ActionBarContributor you might find it
> easier in the end not to. If you look at
> EditingDomainActionBarContributor you will see it is derived from
> IEditorActionBarContributor and makes use of the activation for the
> contributor defined by setActiveEditor.
> If you are only supplying a ViewPart to the Workbench and are not
> worried about the current Editor or Model, then it might be better to
> re-use the actions from EMF and derive your own menu contributions -
> after all you are not sensitive to the EditorPart lifecycle. Or indeed
> bipass the EMF actions altogether...
> Most of what EditingDomainActionBarContributor does using the editor
> part requires it to implement ISelectionProvider and
> IEditingDomainProvider, so if you implement those things you should be
> okay.
> I only offer this advice as I had the same problem, long ago...
> Perhaps Ed will give the definitive word?
>
|
|
| |
| Re: Undo/Redo in EMF based RCP application [message #429069 is a reply to message #425808] |
Tue, 07 April 2009 12:10 |
Eirik Gr
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
Hello
I see that this topic was discussed some time ago, but it gave me some
valuable tips converting the generated editor using IWorkbenchPart (which
both IViewPart and IEditorPart is derived from) instead of IEditorPart.
In my setting, it was not suitable to let the editing of the model be the
central part in th perspective. My preference was to use it as a
supporting view - a kind of model explorer - for a central grapical editor
manipulating time series from simulation runs.
To get started I went through the listing from Eike Stepper as far back as
to July 2005 (
http://dev.eclipse.org/mhonarc/newsLists/news.eclipse.tools. emf/msg10973.html
), where he pointed out that he got a NPE in the EMF code. The NPE was
most probably caused by an almost empty command stack. In my case all the
standard commands (copy, paste, undo/redo and delete) enabled through the
ItemProviderAdapter (and org.eclipse.emf.edit.command) produced a NPE. The
Crate Child and Sibling actions are handled in the supported
ActionBarContributor class generated by the editor and worked as expected.
The reason seemed to be the code filling the command stack with Undo/Redo,
among others commands, was never executed. In the original generated
editor code, this happens in setActiveEditor which call activate and
deactivate and indirectly update. All these members are in class
EditingDomainActionbarContributor. Note that setActiveEditor is also
overriden in the supporting ActionbarContributer class generated by the
editor. This is the most central part where IEditorPart is is used, so
substituting setActiveEditor with e.g. setActivePart supporting IViewPart
(through IWorbenchPart) views instead of editors is rather straight
forward.
In the listing provuded by Eike Stepper from July 2005 this is exactly
what is done in the supporting ActionBarContributor class. The member
starts out as follows:
public void setActivePart(IWorkbenchPart part)
{
// TODO activeEditorPart == super.activeEditor ???
activeEditorPart = part;
// Switch to the new selection provider.
// ...
TODO is actually to copy the code from super.setActiveEditor as questioned
in the code snippet above and adopt it to a view. This gives the following
code:
public void setActivePart(IWorkbenchPart part) {
// nested if clause copied from super.activeEditor
if (part != activeWorkbenchPart) {
if (activeWorkbenchPart != null) {
deactivate();
}
if (part instanceof IEditingDomainProvider) {
activeWorkbenchPart = part;
activate();
}
}
// Switch to the new selection provider.
// ...
As we can see from the code, activate gets called. This is the place where
the command stack actions get enabled. So copying and overriding activate,
deactivate and update from EditingDomainActionbarContributor to the
generated supporting ActionbarContibutor class and adopting IEditorPart
dependent code to IWorkbencpart code (as in setActivePart), the actions
should be enabled, and the editor in the view should behave as expected.
Thanks again for given me a starting point for getting a view enabled
model editor.
As I started out, my belief is a that a model based tree editor will in
many applications only be a supporting view for a main editor. This leads
me to suggest a functionality in EMF supporting both IViewPart and
IEditorPart by using IWorkbenchPart. There are most probably challenges
that I don't see from my restricted knowledge of EMF. But runnung an
editor as a "model explorer" view (IViewPart) without to much changes in
code using the original design I permit myself to suggest that the
decisions makers (who probably don't read this) evaluate this as a future
functionality in EMF.
Thanks Eirik
|
|
|
| Re: Undo/Redo in EMF based RCP application [message #429070 is a reply to message #429069] |
Tue, 07 April 2009 12:47 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Eirik,
A bugzilla feature request with patches or design suggestions for the
types of changes you'd like to see would be most welcome. Even just a
sample application showing what you did to make a view part work would
be an excellent contribution toward incorporating something reusable in
the base framework.
Eirik Grønsund wrote:
> Hello
> I see that this topic was discussed some time ago, but it gave me some
> valuable tips converting the generated editor using IWorkbenchPart
> (which both IViewPart and IEditorPart is derived from) instead of
> IEditorPart.
> In my setting, it was not suitable to let the editing of the model be
> the central part in th perspective. My preference was to use it as a
> supporting view - a kind of model explorer - for a central grapical
> editor manipulating time series from simulation runs.
>
> To get started I went through the listing from Eike Stepper as far
> back as to July 2005 (
> http://dev.eclipse.org/mhonarc/newsLists/news.eclipse.tools. emf/msg10973.html
> ), where he pointed out that he got a NPE in the EMF code. The NPE was
> most probably caused by an almost empty command stack. In my case all
> the standard commands (copy, paste, undo/redo and delete) enabled
> through the ItemProviderAdapter (and org.eclipse.emf.edit.command)
> produced a NPE. The Crate Child and Sibling actions are handled in the
> supported ActionBarContributor class generated by the editor and
> worked as expected.
> The reason seemed to be the code filling the command stack with
> Undo/Redo, among others commands, was never executed. In the original
> generated editor code, this happens in setActiveEditor which call
> activate and deactivate and indirectly update. All these members are
> in class EditingDomainActionbarContributor. Note that setActiveEditor
> is also overriden in the supporting ActionbarContributer class
> generated by the editor. This is the most central part where
> IEditorPart is is used, so substituting setActiveEditor with e.g.
> setActivePart supporting IViewPart (through IWorbenchPart) views
> instead of editors is rather straight forward.
>
> In the listing provuded by Eike Stepper from July 2005 this is exactly
> what is done in the supporting ActionBarContributor class. The member
> starts out as follows:
>
> public void setActivePart(IWorkbenchPart part)
> {
> // TODO activeEditorPart == super.activeEditor ???
> activeEditorPart = part;
>
> // Switch to the new selection provider.
> // ...
>
> TODO is actually to copy the code from super.setActiveEditor as
> questioned in the code snippet above and adopt it to a view. This
> gives the following code:
>
> public void setActivePart(IWorkbenchPart part) {
> // nested if clause copied from super.activeEditor
> if (part != activeWorkbenchPart) {
> if (activeWorkbenchPart != null) {
> deactivate();
> }
> if (part instanceof IEditingDomainProvider) {
> activeWorkbenchPart = part;
> activate();
> }
> }
> // Switch to the new selection provider.
> // ...
>
> As we can see from the code, activate gets called. This is the place
> where the command stack actions get enabled. So copying and overriding
> activate, deactivate and update from EditingDomainActionbarContributor
> to the generated supporting ActionbarContibutor class and adopting
> IEditorPart dependent code to IWorkbencpart code (as in
> setActivePart), the actions should be enabled, and the editor in the
> view should behave as expected.
> Thanks again for given me a starting point for getting a view enabled
> model editor.
>
> As I started out, my belief is a that a model based tree editor will
> in many applications only be a supporting view for a main editor. This
> leads me to suggest a functionality in EMF supporting both IViewPart
> and IEditorPart by using IWorkbenchPart. There are most probably
> challenges that I don't see from my restricted knowledge of EMF. But
> runnung an editor as a "model explorer" view (IViewPart) without to
> much changes in code using the original design I permit myself to
> suggest that the decisions makers (who probably don't read this)
> evaluate this as a future functionality in EMF.
>
> Thanks Eirik
>
>
>
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Undo/Redo in EMF based RCP application [message #429072 is a reply to message #429070] |
Tue, 07 April 2009 13:33 |
Eirik Gr
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
Ed Merks wrote:
> Eirik,
> A bugzilla feature request with patches or design suggestions for the
> types of changes you'd like to see would be most welcome. Even just a
> sample application showing what you did to make a view part work would
> be an excellent contribution toward incorporating something reusable in
> the base framework.
> Eirik Grønsund wrote:
>> Hello
>> I see that this topic was discussed some time ago, but it gave me some
>> valuable tips converting the generated editor using IWorkbenchPart
>> (which both IViewPart and IEditorPart is derived from) instead of
>> IEditorPart.
>> In my setting, it was not suitable to let the editing of the model be
>> the central part in th perspective. My preference was to use it as a
>> supporting view - a kind of model explorer - for a central grapical
>> editor manipulating time series from simulation runs.
>>
>> To get started I went through the listing from Eike Stepper as far
>> back as to July 2005 (
>>
http://dev.eclipse.org/mhonarc/newsLists/news.eclipse.tools. emf/msg10973.html
>> ), where he pointed out that he got a NPE in the EMF code. The NPE was
>> most probably caused by an almost empty command stack. In my case all
>> the standard commands (copy, paste, undo/redo and delete) enabled
>> through the ItemProviderAdapter (and org.eclipse.emf.edit.command)
>> produced a NPE. The Crate Child and Sibling actions are handled in the
>> supported ActionBarContributor class generated by the editor and
>> worked as expected.
>> The reason seemed to be the code filling the command stack with
>> Undo/Redo, among others commands, was never executed. In the original
>> generated editor code, this happens in setActiveEditor which call
>> activate and deactivate and indirectly update. All these members are
>> in class EditingDomainActionbarContributor. Note that setActiveEditor
>> is also overriden in the supporting ActionbarContributer class
>> generated by the editor. This is the most central part where
>> IEditorPart is is used, so substituting setActiveEditor with e.g.
>> setActivePart supporting IViewPart (through IWorbenchPart) views
>> instead of editors is rather straight forward.
>>
>> In the listing provuded by Eike Stepper from July 2005 this is exactly
>> what is done in the supporting ActionBarContributor class. The member
>> starts out as follows:
>>
>> public void setActivePart(IWorkbenchPart part)
>> {
>> // TODO activeEditorPart == super.activeEditor ???
>> activeEditorPart = part;
>>
>> // Switch to the new selection provider.
>> // ...
>>
>> TODO is actually to copy the code from super.setActiveEditor as
>> questioned in the code snippet above and adopt it to a view. This
>> gives the following code:
>>
>> public void setActivePart(IWorkbenchPart part) {
>> // nested if clause copied from super.activeEditor
>> if (part != activeWorkbenchPart) {
>> if (activeWorkbenchPart != null) {
>> deactivate();
>> }
>> if (part instanceof IEditingDomainProvider) {
>> activeWorkbenchPart = part;
>> activate();
>> }
>> }
>> // Switch to the new selection provider.
>> // ...
>>
>> As we can see from the code, activate gets called. This is the place
>> where the command stack actions get enabled. So copying and overriding
>> activate, deactivate and update from EditingDomainActionbarContributor
>> to the generated supporting ActionbarContibutor class and adopting
>> IEditorPart dependent code to IWorkbencpart code (as in
>> setActivePart), the actions should be enabled, and the editor in the
>> view should behave as expected.
>> Thanks again for given me a starting point for getting a view enabled
>> model editor.
>>
>> As I started out, my belief is a that a model based tree editor will
>> in many applications only be a supporting view for a main editor. This
>> leads me to suggest a functionality in EMF supporting both IViewPart
>> and IEditorPart by using IWorkbenchPart. There are most probably
>> challenges that I don't see from my restricted knowledge of EMF. But
>> runnung an editor as a "model explorer" view (IViewPart) without to
>> much changes in code using the original design I permit myself to
>> suggest that the decisions makers (who probably don't read this)
>> evaluate this as a future functionality in EMF.
>>
>> Thanks Eirik
>>
>>
>>
>>
>>
>>
>>
Hello and thanks for a quick response
I am new in this portal, and my posting should have been a reply to
Christian Hauser from Dec 09 2008 and my statement about "decision makers
don't read this" was inappropiate and obviously wrong. Sorry about that.
I will revise and see if I can streamline the code and send a poposal.
Thanks, Eirik
|
|
|
Goto Forum:
Current Time: Wed Apr 24 16:56:45 GMT 2024
Powered by FUDForum. Page generated in 0.03530 seconds |
] 
Search
Help
Register
Login
Home
