Home » Modeling » GMF (Graphical Modeling Framework) » MultiPageEditor and ElementBinding (Dynamic editing domain ID)
| MultiPageEditor and ElementBinding (Dynamic editing domain ID) [message #8512] |
Tue, 08 August 2006 02:05  |
Eclipse User |
|
|
|
Originally posted by: khai.n.situvista.com
I have a metamodel that contains a root element PageSet and subroot
elements Page. I'm implementing a MultiPageEditor where:
* Each Page element is in a separate tab of the MultiPageEditor
* Each tab is hosting the GMF generated editor
* Page is the canvas root of the generated editor
* Each MultiPageEditor has a unique instance of
TransactionalEditingDomain
* All editors within the same MultiPageEditor shares the same
editing domain.
Q1. ElementBinding -- I have a factory class to create and maintain a
registry for the editing domains; the domainID is dynamically generated.
Element binding (which makes use of this domainID to enable the
creation of nodes from the palette) is specified in the plugin.xml; how
do I dynamically declare ElementBinding through code? I do not know all
the possible domainID's beforehand because each instance of the
MultiPageEditor will get a domainID generated for it at runtime.
Q2. Is there a better way to implement shared (but separate) editing
domains for a MultiPageEditor?
Any hints will be greatly appreciated
-- Khai --
|
|
| |
| Re: MultiPageEditor and ElementBinding (Dynamic editing domain ID) [message #11281 is a reply to message #9964] |
Tue, 08 August 2006 22:55  |
| Eclipse User |
|
|
|
Originally posted by: khai.n.situvista.com
Thanks, Linda, that works like a charm:-)
I have a follow-up question to the solution:
In the declaration for ElementBindings in the generated plugin.xml there
is an element called 'advice' [<advice
ref=" org.eclipse.gmf.runtime.diagram.core.advice.notationDepdende nts "/>].
What is it for and is it something I must also take care of when
registering through code? So far I have not done anything with it and
everything seems to be working OK.
Thanks Again!
-- Khai --
Linda Damus wrote:
> Hello Khai,
>
>> Q1. ElementBinding -- I have a factory class to create and maintain a
>> registry for the editing domains; the domainID is dynamically
>> generated. Element binding (which makes use of this domainID to
>> enable the creation of nodes from the palette) is specified in the
>> plugin.xml; how do I dynamically declare ElementBinding through code?
>> I do not know all the possible domainID's beforehand because each
>> instance of the MultiPageEditor will get a domainID generated for it
>> at runtime.
>
> To register a client context through code, you can instantiate a new
> org.eclipse.gmf.runtime.emf.type.core.ClientContext, use #bindId or
> #bindPattern to bind your element types to that context, and register
> your new context with
> ClientContextManager.getInstance().registerClientContext()
>
> Regards,
> Linda
|
|
|
| Re: MultiPageEditor and ElementBinding (Dynamic editing domain ID) [message #12955 is a reply to message #11281] |
Wed, 09 August 2006 13:39 |
 Linda Damus
Messages: 85
Registered: July 2009 |
Member |
|
|
Hi Khai,
The notation dependents advice will destroy any views that are
referencing a semantic element when the semantic element is destroyed by
means of a GMF DestroyElementRequest. You will need to bind this advice
to your client context if you want this behaviour in your application.
Some applications prefer to show the views with an unresolved reference
in cases like this, in which case they can opt to not bind the notation
dependents advice to their client context.
Regards,
Linda
Khai M Nguyen wrote:
> Thanks, Linda, that works like a charm:-)
>
> I have a follow-up question to the solution:
>
> In the declaration for ElementBindings in the generated plugin.xml there
> is an element called 'advice' [<advice
> ref=" org.eclipse.gmf.runtime.diagram.core.advice.notationDepdende nts "/>].
>
> What is it for and is it something I must also take care of when
> registering through code? So far I have not done anything with it and
> everything seems to be working OK.
>
>
> Thanks Again!
>
> -- Khai --
>
> Linda Damus wrote:
>> Hello Khai,
>>
>>> Q1. ElementBinding -- I have a factory class to create and maintain a
>>> registry for the editing domains; the domainID is dynamically
>>> generated. Element binding (which makes use of this domainID to
>>> enable the creation of nodes from the palette) is specified in the
>>> plugin.xml; how do I dynamically declare ElementBinding through
>>> code? I do not know all the possible domainID's beforehand because
>>> each instance of the MultiPageEditor will get a domainID generated
>>> for it at runtime.
>>
>> To register a client context through code, you can instantiate a new
>> org.eclipse.gmf.runtime.emf.type.core.ClientContext, use #bindId or
>> #bindPattern to bind your element types to that context, and register
>> your new context with
>> ClientContextManager.getInstance().registerClientContext()
>>
>> Regards,
>> Linda
|
|
|
| Re: MultiPageEditor and ElementBinding (Dynamic editing domain ID) [message #14465 is a reply to message #12955] |
Thu, 10 August 2006 00:42 |
| Eclipse User |
|
|
|
Originally posted by: khai.n.situvista.com
Thanks, Linda, I'm glad I asked because my application will indeed have
such a feature (destroy the semantic elements). Though that part of the
code is not yet implemented in my application I think you've just saved
me a lot of hair-pulling when I do get to implement it. :-)
-- Khai --
Linda Damus wrote:
> Hi Khai,
>
> The notation dependents advice will destroy any views that are
> referencing a semantic element when the semantic element is destroyed by
> means of a GMF DestroyElementRequest. You will need to bind this advice
> to your client context if you want this behaviour in your application.
> Some applications prefer to show the views with an unresolved reference
> in cases like this, in which case they can opt to not bind the notation
> dependents advice to their client context.
>
> Regards,
> Linda
>
>
> Khai M Nguyen wrote:
>> Thanks, Linda, that works like a charm:-)
>>
>> I have a follow-up question to the solution:
>>
>> In the declaration for ElementBindings in the generated plugin.xml
>> there is an element called 'advice' [<advice
>> ref=" org.eclipse.gmf.runtime.diagram.core.advice.notationDepdende nts "/>].
>>
>> What is it for and is it something I must also take care of when
>> registering through code? So far I have not done anything with it and
>> everything seems to be working OK.
>>
>>
>> Thanks Again!
>>
>> -- Khai --
>>
>> Linda Damus wrote:
>>> Hello Khai,
>>>
>>>> Q1. ElementBinding -- I have a factory class to create and maintain
>>>> a registry for the editing domains; the domainID is dynamically
>>>> generated. Element binding (which makes use of this domainID to
>>>> enable the creation of nodes from the palette) is specified in the
>>>> plugin.xml; how do I dynamically declare ElementBinding through
>>>> code? I do not know all the possible domainID's beforehand because
>>>> each instance of the MultiPageEditor will get a domainID generated
>>>> for it at runtime.
>>>
>>> To register a client context through code, you can instantiate a new
>>> org.eclipse.gmf.runtime.emf.type.core.ClientContext, use #bindId or
>>> #bindPattern to bind your element types to that context, and register
>>> your new context with
>>> ClientContextManager.getInstance().registerClientContext()
>>>
>>> Regards,
>>> Linda
|
|
|
| Re: MultiPageEditor and ElementBinding (Dynamic editing domain ID) [message #15999 is a reply to message #14465] |
Fri, 11 August 2006 17:02 |
| Eclipse User |
|
|
|
Originally posted by: lynchjack.hotmail.com
Hi Khai,
Sorry to interrupt your thread, but it looks like your doing pretty much
what I'm about to attempt to do.
I've posted already on "Nesting a GMF FileDiagramEditor inside a
org.eclipse.ui.part.MultiPageEditorPart", the question basically is how are
you getting the extensions defined in the generated GMF editor to get
realized once that editor is nested within a MultiPageEditor? The
extensions depend on editorID, so the editorID of the MultiPageEditor will
be different.
Thanks,
Jack
"Khai M Nguyen" <khai.n@situvista.com> wrote in message
news:ebdvdj$8im$1@utils.eclipse.org...
> Thanks, Linda, I'm glad I asked because my application will indeed have
> such a feature (destroy the semantic elements). Though that part of the
> code is not yet implemented in my application I think you've just saved me
> a lot of hair-pulling when I do get to implement it. :-)
>
> -- Khai --
>
> Linda Damus wrote:
>> Hi Khai,
>>
>> The notation dependents advice will destroy any views that are
>> referencing a semantic element when the semantic element is destroyed by
>> means of a GMF DestroyElementRequest. You will need to bind this advice
>> to your client context if you want this behaviour in your application.
>> Some applications prefer to show the views with an unresolved reference
>> in cases like this, in which case they can opt to not bind the notation
>> dependents advice to their client context.
>>
>> Regards,
>> Linda
>>
>>
>> Khai M Nguyen wrote:
>>> Thanks, Linda, that works like a charm:-)
>>>
>>> I have a follow-up question to the solution:
>>>
>>> In the declaration for ElementBindings in the generated plugin.xml there
>>> is an element called 'advice' [<advice
>>> ref=" org.eclipse.gmf.runtime.diagram.core.advice.notationDepdende nts "/>].
>>>
>>> What is it for and is it something I must also take care of when
>>> registering through code? So far I have not done anything with it and
>>> everything seems to be working OK.
>>>
>>>
>>> Thanks Again!
>>>
>>> -- Khai --
>>>
>>> Linda Damus wrote:
>>>> Hello Khai,
>>>>
>>>>> Q1. ElementBinding -- I have a factory class to create and maintain a
>>>>> registry for the editing domains; the domainID is dynamically
>>>>> generated. Element binding (which makes use of this domainID to
>>>>> enable the creation of nodes from the palette) is specified in the
>>>>> plugin.xml; how do I dynamically declare ElementBinding through code?
>>>>> I do not know all the possible domainID's beforehand because each
>>>>> instance of the MultiPageEditor will get a domainID generated for it
>>>>> at runtime.
>>>>
>>>> To register a client context through code, you can instantiate a new
>>>> org.eclipse.gmf.runtime.emf.type.core.ClientContext, use #bindId or
>>>> #bindPattern to bind your element types to that context, and register
>>>> your new context with
>>>> ClientContextManager.getInstance().registerClientContext()
>>>>
>>>> Regards,
>>>> Linda
|
|
|
| Re: MultiPageEditor and ElementBinding (Dynamic editing domain ID) [message #16103 is a reply to message #15999] |
Sat, 12 August 2006 03:41 |
| Eclipse User |
|
|
|
Originally posted by: khai.n.situvista.com
Hi, Jack, I'm glad there are at least a few of us hunting-n-pecking to
create a MultiPageEditor:-)
This is what I've done so far:
== EditorInput ==
I have a custom IEditorInput (which is given to the embedded
DiagramEditor) that returns a custom IStorage for getStorage().
== IStorage ==
This is actually a wrapper around
org.eclipse.core.internal.resources.File that adds 1 additional property
'pageID'. This ID is used for locating and loading the proper Page as
the diagram root in the DocumentProvider.
== Editing Domain ==
Since all the pages of the editor must share the same EditingDomain to
be seamless I have a Factory that dispatches the proper static instances
of the EditingDomain to the pages(binding elements dynamically to the
EditingDomain was the topic of this thread).
== DocumentProvider ==
Like wise I have a factory to dispatch shared instances of a custom
DocumentProvider; this provider uses a custom IStorage (mentioned above)
to load the correct 'root' diagram for each embedded DiagramEditor
== Palette ==
With the palette I overrode .createSite() of the XXXMultiPageEditor to
return a custom subclass of MultiPageEditorSite; this custom class
simply returns the ID of the GMF generated editor in getId() instead of
the ID of the XXXMultiPageEditor.
== ModelingAssistant ==
For ModelingAssitant I made the XXXMultiPageEditor implement
IDiagramWorkbenchPart and delegated the declared methods:
getDiagramGraphicalViewer();
getDiagramEditDomain();
getDiagram();
getDiagramEditPart();
to the active DiagramEditor (if there is one otherwise null).
== GlobalActionHandlerProviders ==
The IDiagramWorkbenchPart interface is also required by the
GlobalActionHandlerProviders, additionally the View ID in the handler
providers' extension declaration must be changed to the ID of the
XXXMultiPageEditor.
== Validation ==
Instead of using the default Validation providers I contributed a custom
ValidationProvider and a custom MarkerNavigationProvider (the default
navigator will assume all your markers are pointing to elements on the
active page and so will not navigate successfully to any element(s) not
found on the active page). The generated classes for these were a good
place to start and only required some minor modification.
== Print/PrintPreview ==
These action utilizes 'instanceof DiagramEditor' in their code so will
not work as is. These are going to have to be a custom actions anyway
since the default actions would not know about additional 'pages'
== Clipboard ==
The GlobalActionHandlers are active so the menus are there but the
actions would have to be custom (unless the actions work out-of-the-box
for you) which mine don't:-(.
I still have a number of items to finish up but they're mostly
application specific.
-- Khai --
Jack Lynch wrote:
> Hi Khai,
>
> Sorry to interrupt your thread, but it looks like your doing pretty much
> what I'm about to attempt to do.
>
> I've posted already on "Nesting a GMF FileDiagramEditor inside a
> org.eclipse.ui.part.MultiPageEditorPart", the question basically is how are
> you getting the extensions defined in the generated GMF editor to get
> realized once that editor is nested within a MultiPageEditor? The
> extensions depend on editorID, so the editorID of the MultiPageEditor will
> be different.
>
> Thanks,
> Jack
>
>
> "Khai M Nguyen" <khai.n@situvista.com> wrote in message
> news:ebdvdj$8im$1@utils.eclipse.org...
>> Thanks, Linda, I'm glad I asked because my application will indeed have
>> such a feature (destroy the semantic elements). Though that part of the
>> code is not yet implemented in my application I think you've just saved me
>> a lot of hair-pulling when I do get to implement it. :-)
>>
>> -- Khai --
>>
>> Linda Damus wrote:
>>> Hi Khai,
>>>
>>> The notation dependents advice will destroy any views that are
>>> referencing a semantic element when the semantic element is destroyed by
>>> means of a GMF DestroyElementRequest. You will need to bind this advice
>>> to your client context if you want this behaviour in your application.
>>> Some applications prefer to show the views with an unresolved reference
>>> in cases like this, in which case they can opt to not bind the notation
>>> dependents advice to their client context.
>>>
>>> Regards,
>>> Linda
>>>
>>>
>>> Khai M Nguyen wrote:
>>>> Thanks, Linda, that works like a charm:-)
>>>>
>>>> I have a follow-up question to the solution:
>>>>
>>>> In the declaration for ElementBindings in the generated plugin.xml there
>>>> is an element called 'advice' [<advice
>>>> ref=" org.eclipse.gmf.runtime.diagram.core.advice.notationDepdende nts "/>].
>>>>
>>>> What is it for and is it something I must also take care of when
>>>> registering through code? So far I have not done anything with it and
>>>> everything seems to be working OK.
>>>>
>>>>
>>>> Thanks Again!
>>>>
>>>> -- Khai --
>>>>
>>>> Linda Damus wrote:
>>>>> Hello Khai,
>>>>>
>>>>>> Q1. ElementBinding -- I have a factory class to create and maintain a
>>>>>> registry for the editing domains; the domainID is dynamically
>>>>>> generated. Element binding (which makes use of this domainID to
>>>>>> enable the creation of nodes from the palette) is specified in the
>>>>>> plugin.xml; how do I dynamically declare ElementBinding through code?
>>>>>> I do not know all the possible domainID's beforehand because each
>>>>>> instance of the MultiPageEditor will get a domainID generated for it
>>>>>> at runtime.
>>>>> To register a client context through code, you can instantiate a new
>>>>> org.eclipse.gmf.runtime.emf.type.core.ClientContext, use #bindId or
>>>>> #bindPattern to bind your element types to that context, and register
>>>>> your new context with
>>>>> ClientContextManager.getInstance().registerClientContext()
>>>>>
>>>>> Regards,
>>>>> Linda
>
>
|
|
|
| Re: MultiPageEditor and ElementBinding (Dynamic editing domain ID) [message #17323 is a reply to message #16103] |
Mon, 14 August 2006 16:44 |
| Eclipse User |
|
|
|
Originally posted by: lynchjack.hotmail.com
Thanks Khai, got to briefly try some of this this morning and it went well!
"Khai M Nguyen" <khai.n@situvista.com> wrote in message
news:ebjil1$en7$1@utils.eclipse.org...
> Hi, Jack, I'm glad there are at least a few of us hunting-n-pecking to
> create a MultiPageEditor:-)
>
> This is what I've done so far:
>
> == EditorInput ==
> I have a custom IEditorInput (which is given to the embedded
> DiagramEditor) that returns a custom IStorage for getStorage().
>
>
> == IStorage ==
> This is actually a wrapper around org.eclipse.core.internal.resources.File
> that adds 1 additional property 'pageID'. This ID is used for locating
> and loading the proper Page as the diagram root in the DocumentProvider.
>
> == Editing Domain ==
> Since all the pages of the editor must share the same EditingDomain to be
> seamless I have a Factory that dispatches the proper static instances of
> the EditingDomain to the pages(binding elements dynamically to the
> EditingDomain was the topic of this thread).
>
>
> == DocumentProvider ==
> Like wise I have a factory to dispatch shared instances of a custom
> DocumentProvider; this provider uses a custom IStorage (mentioned above)
> to load the correct 'root' diagram for each embedded DiagramEditor
>
>
> == Palette ==
> With the palette I overrode .createSite() of the XXXMultiPageEditor to
> return a custom subclass of MultiPageEditorSite; this custom class simply
> returns the ID of the GMF generated editor in getId() instead of the ID of
> the XXXMultiPageEditor.
>
>
> == ModelingAssistant ==
> For ModelingAssitant I made the XXXMultiPageEditor implement
> IDiagramWorkbenchPart and delegated the declared methods:
> getDiagramGraphicalViewer();
> getDiagramEditDomain();
> getDiagram();
> getDiagramEditPart();
>
> to the active DiagramEditor (if there is one otherwise null).
>
>
> == GlobalActionHandlerProviders ==
> The IDiagramWorkbenchPart interface is also required by the
> GlobalActionHandlerProviders, additionally the View ID in the handler
> providers' extension declaration must be changed to the ID of the
> XXXMultiPageEditor.
>
>
> == Validation ==
> Instead of using the default Validation providers I contributed a custom
> ValidationProvider and a custom MarkerNavigationProvider (the default
> navigator will assume all your markers are pointing to elements on the
> active page and so will not navigate successfully to any element(s) not
> found on the active page). The generated classes for these were a good
> place to start and only required some minor modification.
>
>
> == Print/PrintPreview ==
> These action utilizes 'instanceof DiagramEditor' in their code so will not
> work as is. These are going to have to be a custom actions anyway since
> the default actions would not know about additional 'pages'
>
> == Clipboard ==
> The GlobalActionHandlers are active so the menus are there but the actions
> would have to be custom (unless the actions work out-of-the-box for you)
> which mine don't:-(.
>
> I still have a number of items to finish up but they're mostly application
> specific.
>
>
> -- Khai --
>
>
>
>
> Jack Lynch wrote:
>> Hi Khai,
>>
>> Sorry to interrupt your thread, but it looks like your doing pretty much
>> what I'm about to attempt to do.
>>
>> I've posted already on "Nesting a GMF FileDiagramEditor inside a
>> org.eclipse.ui.part.MultiPageEditorPart", the question basically is how
>> are you getting the extensions defined in the generated GMF editor to get
>> realized once that editor is nested within a MultiPageEditor? The
>> extensions depend on editorID, so the editorID of the MultiPageEditor
>> will be different.
>>
>> Thanks,
>> Jack
>>
>>
>> "Khai M Nguyen" <khai.n@situvista.com> wrote in message
>> news:ebdvdj$8im$1@utils.eclipse.org...
>>> Thanks, Linda, I'm glad I asked because my application will indeed have
>>> such a feature (destroy the semantic elements). Though that part of the
>>> code is not yet implemented in my application I think you've just saved
>>> me a lot of hair-pulling when I do get to implement it. :-)
>>>
>>> -- Khai --
>>>
>>> Linda Damus wrote:
>>>> Hi Khai,
>>>>
>>>> The notation dependents advice will destroy any views that are
>>>> referencing a semantic element when the semantic element is destroyed
>>>> by means of a GMF DestroyElementRequest. You will need to bind this
>>>> advice to your client context if you want this behaviour in your
>>>> application. Some applications prefer to show the views with an
>>>> unresolved reference in cases like this, in which case they can opt to
>>>> not bind the notation dependents advice to their client context.
>>>>
>>>> Regards,
>>>> Linda
>>>>
>>>>
>>>> Khai M Nguyen wrote:
>>>>> Thanks, Linda, that works like a charm:-)
>>>>>
>>>>> I have a follow-up question to the solution:
>>>>>
>>>>> In the declaration for ElementBindings in the generated plugin.xml
>>>>> there is an element called 'advice' [<advice
>>>>> ref=" org.eclipse.gmf.runtime.diagram.core.advice.notationDepdende nts "/>].
>>>>>
>>>>> What is it for and is it something I must also take care of when
>>>>> registering through code? So far I have not done anything with it and
>>>>> everything seems to be working OK.
>>>>>
>>>>>
>>>>> Thanks Again!
>>>>>
>>>>> -- Khai --
>>>>>
>>>>> Linda Damus wrote:
>>>>>> Hello Khai,
>>>>>>
>>>>>>> Q1. ElementBinding -- I have a factory class to create and maintain
>>>>>>> a registry for the editing domains; the domainID is dynamically
>>>>>>> generated. Element binding (which makes use of this domainID to
>>>>>>> enable the creation of nodes from the palette) is specified in the
>>>>>>> plugin.xml; how do I dynamically declare ElementBinding through
>>>>>>> code? I do not know all the possible domainID's beforehand because
>>>>>>> each instance of the MultiPageEditor will get a domainID generated
>>>>>>> for it at runtime.
>>>>>> To register a client context through code, you can instantiate a new
>>>>>> org.eclipse.gmf.runtime.emf.type.core.ClientContext, use #bindId or
>>>>>> #bindPattern to bind your element types to that context, and register
>>>>>> your new context with
>>>>>> ClientContextManager.getInstance().registerClientContext()
>>>>>>
>>>>>> Regards,
>>>>>> Linda
>>
|
|
|
| Re: MultiPageEditor and ElementBinding (Dynamic editing domain ID) [message #170852 is a reply to message #17323] |
Thu, 31 January 2008 11:35 |
Kristian O'Connor
Messages: 29
Registered: July 2009 |
Junior Member |
|
|
Hi all -
Thanks very much for these posts - they have helped greatly in writing a
multipageeditor with an page that is a GMF editor.... :)
I found that in addition to the GlobalActionHandlerProviders bit - the
necessity to make the following changes to the generated GMF editor in order
to get the 'delete' key to work. This also applies to (gef zoom +/- ,
direct edit, toggleRouter) global actions.
I am posting this to save someone else a couple of days trying to figure it
out...
in the class - DiagramDocumentEditor there is a method
selectionChanged(IWorkbenchPart part, ISelection selection)
which points to its super implementation in the class GraphicalEditor, you
will notce that it checks here that the ActiveEditor is 'this' (The GMF
Editor) which of course it is not! Since the editor is in fact your
MutipageEditor...
The solution is to change this in your generated gmf editor class... you
will also have to copy up the 'private static class ActionIDList', the List
selectionActions and override the getSelectionActions() method.
eg.
@Override
protected List getSelectionActions() {
return selectionActions;
}
@Override
public void selectionChanged(IWorkbenchPart part, ISelection selection) {
// Change the decision to cater for your multi page editor
if (getSite().getPage().getActiveEditor() instanceof YourMultiPageEditor)
updateActions(selectionActions);
}
This will allow the updateActions method to be called ... thereby allowing
the keybindings to be set correctly.
Hope that made sense.
Regards,
Kristian.
"Jack Lynch" <lynchjack@hotmail.com> wrote in message
news:ebq9as$laq$1@utils.eclipse.org...
> Thanks Khai, got to briefly try some of this this morning and it went
> well!
>
> "Khai M Nguyen" <khai.n@situvista.com> wrote in message
> news:ebjil1$en7$1@utils.eclipse.org...
>> Hi, Jack, I'm glad there are at least a few of us hunting-n-pecking to
>> create a MultiPageEditor:-)
>>
>> This is what I've done so far:
>>
>> == EditorInput ==
>> I have a custom IEditorInput (which is given to the embedded
>> DiagramEditor) that returns a custom IStorage for getStorage().
>>
>>
>> == IStorage ==
>> This is actually a wrapper around
>> org.eclipse.core.internal.resources.File that adds 1 additional property
>> 'pageID'. This ID is used for locating and loading the proper Page as
>> the diagram root in the DocumentProvider.
>>
>> == Editing Domain ==
>> Since all the pages of the editor must share the same EditingDomain to be
>> seamless I have a Factory that dispatches the proper static instances of
>> the EditingDomain to the pages(binding elements dynamically to the
>> EditingDomain was the topic of this thread).
>>
>>
>> == DocumentProvider ==
>> Like wise I have a factory to dispatch shared instances of a custom
>> DocumentProvider; this provider uses a custom IStorage (mentioned above)
>> to load the correct 'root' diagram for each embedded DiagramEditor
>>
>>
>> == Palette ==
>> With the palette I overrode .createSite() of the XXXMultiPageEditor to
>> return a custom subclass of MultiPageEditorSite; this custom class simply
>> returns the ID of the GMF generated editor in getId() instead of the ID
>> of the XXXMultiPageEditor.
>>
>>
>> == ModelingAssistant ==
>> For ModelingAssitant I made the XXXMultiPageEditor implement
>> IDiagramWorkbenchPart and delegated the declared methods:
>> getDiagramGraphicalViewer();
>> getDiagramEditDomain();
>> getDiagram();
>> getDiagramEditPart();
>>
>> to the active DiagramEditor (if there is one otherwise null).
>>
>>
>> == GlobalActionHandlerProviders ==
>> The IDiagramWorkbenchPart interface is also required by the
>> GlobalActionHandlerProviders, additionally the View ID in the handler
>> providers' extension declaration must be changed to the ID of the
>> XXXMultiPageEditor.
>>
>>
>> == Validation ==
>> Instead of using the default Validation providers I contributed a custom
>> ValidationProvider and a custom MarkerNavigationProvider (the default
>> navigator will assume all your markers are pointing to elements on the
>> active page and so will not navigate successfully to any element(s) not
>> found on the active page). The generated classes for these were a good
>> place to start and only required some minor modification.
>>
>>
>> == Print/PrintPreview ==
>> These action utilizes 'instanceof DiagramEditor' in their code so will
>> not work as is. These are going to have to be a custom actions anyway
>> since the default actions would not know about additional 'pages'
>>
>> == Clipboard ==
>> The GlobalActionHandlers are active so the menus are there but the
>> actions would have to be custom (unless the actions work out-of-the-box
>> for you) which mine don't:-(.
>>
>> I still have a number of items to finish up but they're mostly
>> application specific.
>>
>>
>> -- Khai --
>>
>>
>>
>>
>> Jack Lynch wrote:
>>> Hi Khai,
>>>
>>> Sorry to interrupt your thread, but it looks like your doing pretty much
>>> what I'm about to attempt to do.
>>>
>>> I've posted already on "Nesting a GMF FileDiagramEditor inside a
>>> org.eclipse.ui.part.MultiPageEditorPart", the question basically is how
>>> are you getting the extensions defined in the generated GMF editor to
>>> get realized once that editor is nested within a MultiPageEditor? The
>>> extensions depend on editorID, so the editorID of the MultiPageEditor
>>> will be different.
>>>
>>> Thanks,
>>> Jack
>>>
>>>
>>> "Khai M Nguyen" <khai.n@situvista.com> wrote in message
>>> news:ebdvdj$8im$1@utils.eclipse.org...
>>>> Thanks, Linda, I'm glad I asked because my application will indeed have
>>>> such a feature (destroy the semantic elements). Though that part of
>>>> the code is not yet implemented in my application I think you've just
>>>> saved me a lot of hair-pulling when I do get to implement it. :-)
>>>>
>>>> -- Khai --
>>>>
>>>> Linda Damus wrote:
>>>>> Hi Khai,
>>>>>
>>>>> The notation dependents advice will destroy any views that are
>>>>> referencing a semantic element when the semantic element is destroyed
>>>>> by means of a GMF DestroyElementRequest. You will need to bind this
>>>>> advice to your client context if you want this behaviour in your
>>>>> application. Some applications prefer to show the views with an
>>>>> unresolved reference in cases like this, in which case they can opt to
>>>>> not bind the notation dependents advice to their client context.
>>>>>
>>>>> Regards,
>>>>> Linda
>>>>>
>>>>>
>>>>> Khai M Nguyen wrote:
>>>>>> Thanks, Linda, that works like a charm:-)
>>>>>>
>>>>>> I have a follow-up question to the solution:
>>>>>>
>>>>>> In the declaration for ElementBindings in the generated plugin.xml
>>>>>> there is an element called 'advice' [<advice
>>>>>> ref=" org.eclipse.gmf.runtime.diagram.core.advice.notationDepdende nts "/>].
>>>>>>
>>>>>> What is it for and is it something I must also take care of when
>>>>>> registering through code? So far I have not done anything with it
>>>>>> and everything seems to be working OK.
>>>>>>
>>>>>>
>>>>>> Thanks Again!
>>>>>>
>>>>>> -- Khai --
>>>>>>
>>>>>> Linda Damus wrote:
>>>>>>> Hello Khai,
>>>>>>>
>>>>>>>> Q1. ElementBinding -- I have a factory class to create and maintain
>>>>>>>> a registry for the editing domains; the domainID is dynamically
>>>>>>>> generated. Element binding (which makes use of this domainID to
>>>>>>>> enable the creation of nodes from the palette) is specified in the
>>>>>>>> plugin.xml; how do I dynamically declare ElementBinding through
>>>>>>>> code? I do not know all the possible domainID's beforehand because
>>>>>>>> each instance of the MultiPageEditor will get a domainID generated
>>>>>>>> for it at runtime.
>>>>>>> To register a client context through code, you can instantiate a new
>>>>>>> org.eclipse.gmf.runtime.emf.type.core.ClientContext, use #bindId or
>>>>>>> #bindPattern to bind your element types to that context, and
>>>>>>> register your new context with
>>>>>>> ClientContextManager.getInstance().registerClientContext()
>>>>>>>
>>>>>>> Regards,
>>>>>>> Linda
>>>
>
|
|
|
| Re: MultiPageEditor and ElementBinding (Dynamic editing domain ID) [message #175637 is a reply to message #170852] |
Tue, 04 March 2008 16:09 |
Kristian O'Connor
Messages: 29
Registered: July 2009 |
Junior Member |
|
|
@Override
public void selectionChanged(IWorkbenchPart part, ISelection selection)
{
if (part instanceof YourMultiPageEditor)
updateActions(super.getSelectionActions());
else
super.selectionChanged(part, selection);
}
is a cleaner solution to the code I provided, thanks to Tomoko Kitamura for
that...
"Kristian" <kristian.oconnor@gmail.com> wrote in message
news:fnscpn$hgr$1@build.eclipse.org...
> Hi all -
>
> Thanks very much for these posts - they have helped greatly in writing a
> multipageeditor with an page that is a GMF editor.... :)
>
> I found that in addition to the GlobalActionHandlerProviders bit - the
> necessity to make the following changes to the generated GMF editor in
> order to get the 'delete' key to work. This also applies to (gef zoom +/-
> , direct edit, toggleRouter) global actions.
>
>
> I am posting this to save someone else a couple of days trying to figure
> it out...
>
>
>
> in the class - DiagramDocumentEditor there is a method
>
> selectionChanged(IWorkbenchPart part, ISelection selection)
>
> which points to its super implementation in the class GraphicalEditor, you
> will notce that it checks here that the ActiveEditor is 'this' (The GMF
> Editor) which of course it is not! Since the editor is in fact your
> MutipageEditor...
>
>
>
> The solution is to change this in your generated gmf editor class... you
> will also have to copy up the 'private static class ActionIDList', the
> List selectionActions and override the getSelectionActions() method.
>
>
>
> eg.
>
> @Override
>
> protected List getSelectionActions() {
>
> return selectionActions;
>
> }
>
>
> @Override
>
> public void selectionChanged(IWorkbenchPart part, ISelection selection) {
>
> // Change the decision to cater for your multi page editor
>
> if (getSite().getPage().getActiveEditor() instanceof YourMultiPageEditor)
>
> updateActions(selectionActions);
>
> }
>
> This will allow the updateActions method to be called ... thereby allowing
> the keybindings to be set correctly.
>
> Hope that made sense.
>
> Regards,
> Kristian.
>
>
>
> "Jack Lynch" <lynchjack@hotmail.com> wrote in message
> news:ebq9as$laq$1@utils.eclipse.org...
>> Thanks Khai, got to briefly try some of this this morning and it went
>> well!
>>
>> "Khai M Nguyen" <khai.n@situvista.com> wrote in message
>> news:ebjil1$en7$1@utils.eclipse.org...
>>> Hi, Jack, I'm glad there are at least a few of us hunting-n-pecking to
>>> create a MultiPageEditor:-)
>>>
>>> This is what I've done so far:
>>>
>>> == EditorInput ==
>>> I have a custom IEditorInput (which is given to the embedded
>>> DiagramEditor) that returns a custom IStorage for getStorage().
>>>
>>>
>>> == IStorage ==
>>> This is actually a wrapper around
>>> org.eclipse.core.internal.resources.File that adds 1 additional property
>>> 'pageID'. This ID is used for locating and loading the proper Page as
>>> the diagram root in the DocumentProvider.
>>>
>>> == Editing Domain ==
>>> Since all the pages of the editor must share the same EditingDomain to
>>> be seamless I have a Factory that dispatches the proper static instances
>>> of the EditingDomain to the pages(binding elements dynamically to the
>>> EditingDomain was the topic of this thread).
>>>
>>>
>>> == DocumentProvider ==
>>> Like wise I have a factory to dispatch shared instances of a custom
>>> DocumentProvider; this provider uses a custom IStorage (mentioned above)
>>> to load the correct 'root' diagram for each embedded DiagramEditor
>>>
>>>
>>> == Palette ==
>>> With the palette I overrode .createSite() of the XXXMultiPageEditor to
>>> return a custom subclass of MultiPageEditorSite; this custom class
>>> simply returns the ID of the GMF generated editor in getId() instead of
>>> the ID of the XXXMultiPageEditor.
>>>
>>>
>>> == ModelingAssistant ==
>>> For ModelingAssitant I made the XXXMultiPageEditor implement
>>> IDiagramWorkbenchPart and delegated the declared methods:
>>> getDiagramGraphicalViewer();
>>> getDiagramEditDomain();
>>> getDiagram();
>>> getDiagramEditPart();
>>>
>>> to the active DiagramEditor (if there is one otherwise null).
>>>
>>>
>>> == GlobalActionHandlerProviders ==
>>> The IDiagramWorkbenchPart interface is also required by the
>>> GlobalActionHandlerProviders, additionally the View ID in the handler
>>> providers' extension declaration must be changed to the ID of the
>>> XXXMultiPageEditor.
>>>
>>>
>>> == Validation ==
>>> Instead of using the default Validation providers I contributed a custom
>>> ValidationProvider and a custom MarkerNavigationProvider (the default
>>> navigator will assume all your markers are pointing to elements on the
>>> active page and so will not navigate successfully to any element(s) not
>>> found on the active page). The generated classes for these were a good
>>> place to start and only required some minor modification.
>>>
>>>
>>> == Print/PrintPreview ==
>>> These action utilizes 'instanceof DiagramEditor' in their code so will
>>> not work as is. These are going to have to be a custom actions anyway
>>> since the default actions would not know about additional 'pages'
>>>
>>> == Clipboard ==
>>> The GlobalActionHandlers are active so the menus are there but the
>>> actions would have to be custom (unless the actions work out-of-the-box
>>> for you) which mine don't:-(.
>>>
>>> I still have a number of items to finish up but they're mostly
>>> application specific.
>>>
>>>
>>> -- Khai --
>>>
>>>
>>>
>>>
>>> Jack Lynch wrote:
>>>> Hi Khai,
>>>>
>>>> Sorry to interrupt your thread, but it looks like your doing pretty
>>>> much what I'm about to attempt to do.
>>>>
>>>> I've posted already on "Nesting a GMF FileDiagramEditor inside a
>>>> org.eclipse.ui.part.MultiPageEditorPart", the question basically is how
>>>> are you getting the extensions defined in the generated GMF editor to
>>>> get realized once that editor is nested within a MultiPageEditor? The
>>>> extensions depend on editorID, so the editorID of the MultiPageEditor
>>>> will be different.
>>>>
>>>> Thanks,
>>>> Jack
>>>>
>>>>
>>>> "Khai M Nguyen" <khai.n@situvista.com> wrote in message
>>>> news:ebdvdj$8im$1@utils.eclipse.org...
>>>>> Thanks, Linda, I'm glad I asked because my application will indeed
>>>>> have such a feature (destroy the semantic elements). Though that part
>>>>> of the code is not yet implemented in my application I think you've
>>>>> just saved me a lot of hair-pulling when I do get to implement it. :-)
>>>>>
>>>>> -- Khai --
>>>>>
>>>>> Linda Damus wrote:
>>>>>> Hi Khai,
>>>>>>
>>>>>> The notation dependents advice will destroy any views that are
>>>>>> referencing a semantic element when the semantic element is destroyed
>>>>>> by means of a GMF DestroyElementRequest. You will need to bind this
>>>>>> advice to your client context if you want this behaviour in your
>>>>>> application. Some applications prefer to show the views with an
>>>>>> unresolved reference in cases like this, in which case they can opt
>>>>>> to not bind the notation dependents advice to their client context.
>>>>>>
>>>>>> Regards,
>>>>>> Linda
>>>>>>
>>>>>>
>>>>>> Khai M Nguyen wrote:
>>>>>>> Thanks, Linda, that works like a charm:-)
>>>>>>>
>>>>>>> I have a follow-up question to the solution:
>>>>>>>
>>>>>>> In the declaration for ElementBindings in the generated plugin.xml
>>>>>>> there is an element called 'advice' [<advice
>>>>>>> ref=" org.eclipse.gmf.runtime.diagram.core.advice.notationDepdende nts "/>].
>>>>>>>
>>>>>>> What is it for and is it something I must also take care of when
>>>>>>> registering through code? So far I have not done anything with it
>>>>>>> and everything seems to be working OK.
>>>>>>>
>>>>>>>
>>>>>>> Thanks Again!
>>>>>>>
>>>>>>> -- Khai --
>>>>>>>
>>>>>>> Linda Damus wrote:
>>>>>>>> Hello Khai,
>>>>>>>>
>>>>>>>>> Q1. ElementBinding -- I have a factory class to create and
>>>>>>>>> maintain a registry for the editing domains; the domainID is
>>>>>>>>> dynamically generated. Element binding (which makes use of this
>>>>>>>>> domainID to enable the creation of nodes from the palette) is
>>>>>>>>> specified in the plugin.xml; how do I dynamically declare
>>>>>>>>> ElementBinding through code? I do not know all the possible
>>>>>>>>> domainID's beforehand because each instance of the MultiPageEditor
>>>>>>>>> will get a domainID generated for it at runtime.
>>>>>>>> To register a client context through code, you can instantiate a
>>>>>>>> new org.eclipse.gmf.runtime.emf.type.core.ClientContext, use
>>>>>>>> #bindId or #bindPattern to bind your element types to that context,
>>>>>>>> and register your new context with
>>>>>>>> ClientContextManager.getInstance().registerClientContext()
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Linda
>>>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Sat Nov 09 00:08:13 GMT 2024
Powered by FUDForum. Page generated in 0.05542 seconds |
] 
Search
Help
Register
Login
Home
