Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EditingDomainActionBarContributor#init(IActionBars)
EditingDomainActionBarContributor#init(IActionBars) [message #431274] Tue, 07 July 2009 09:54 Go to next message
Ali Akar is currently offline Ali AkarFriend
Messages: 29
Registered: July 2009
Junior Member
Hi all,

The Delete/Copy/Paste... actions are instantiated directly in the init
method ? I think, it would be better that each action is created in an
externalized method, something like this :

deleteAction = CreateDeleteAction();

It will be easiest to override this method instead of overriding the init.

I'm asking if its relevant to create an enhancement bug for this issue ?

Thanks for Ed and all EMF guys,
Ali
Re: EditingDomainActionBarContributor#init(IActionBars) [message #431277 is a reply to message #431274] Tue, 07 July 2009 10:57 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30687
Registered: July 2009
Senior Member
Ali,

Yes, that does seem more flexible. Feel free to open a bugzilla.


Ali Akar wrote:
> Hi all,
>
> The Delete/Copy/Paste... actions are instantiated directly in the init
> method ? I think, it would be better that each action is created in an
> externalized method, something like this :
>
> deleteAction = CreateDeleteAction();
>
> It will be easiest to override this method instead of overriding the
> init.
>
> I'm asking if its relevant to create an enhancement bug for this issue ?
>
> Thanks for Ed and all EMF guys,
> Ali
Re: EditingDomainActionBarContributor#init(IActionBars) [message #431280 is a reply to message #431277] Tue, 07 July 2009 12:57 Go to previous messageGo to next message
Ali Akar is currently offline Ali AkarFriend
Messages: 29
Registered: July 2009
Junior Member
Thanks Ed for your answer,

I have just one more proposition, if it relevant !!

The EMF Delete/Copy/Paste... actions expect that the editing domain is
never null, but tools built on EMF might not guarantee this fact. In our
project, for example, we have to create context menus including above
named actions for the currently selected element (EObject) in a tree
viewer. Under certain condition, it happens, that the selected element
is a proxy object, for which the actions are unable to retrieve an
editing domain.

An error dialog is shown after selecting these objects, so what I
suggest is that these actions support the case when editing domain is null.

What I have done is to override the createCommand(Collection<?>) of
these action returning an UnexecutableCommand.INSTANCE when editing
domain is null. see below the snippet :

-----
@Override
public Command createCommand(Collection<?> selection) {
if (domain != null) {
return super.createCommand(selection);
}
return UnexecutableCommand.INSTANCE;
}
-----

Thanks,
Ali

Ed Merks a écrit :

> Ali,
>
> Yes, that does seem more flexible. Feel free to open a bugzilla.
>
>
> Ali Akar wrote:
>> Hi all,
>>
>> The Delete/Copy/Paste... actions are instantiated directly in the init
>> method ? I think, it would be better that each action is created in an
>> externalized method, something like this :
>>
>> deleteAction = CreateDeleteAction();
>>
>> It will be easiest to override this method instead of overriding the
>> init.
>>
>> I'm asking if its relevant to create an enhancement bug for this issue ?
>>
>> Thanks for Ed and all EMF guys,
>> Ali
Re: EditingDomainActionBarContributor#init(IActionBars) [message #431281 is a reply to message #431280] Tue, 07 July 2009 13:30 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30687
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------040607060304010103040000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Ali,

Shouldn't the domain be determinable from the workbench part?

public void setActiveWorkbenchPart(IWorkbenchPart workbenchPart)
{
if (workbenchPart instanceof IEditingDomainProvider)
{
domain =
((IEditingDomainProvider)workbenchPart).getEditingDomain();
}
}


Ali Akar wrote:
> Thanks Ed for your answer,
>
> I have just one more proposition, if it relevant !!
>
> The EMF Delete/Copy/Paste... actions expect that the editing domain is
> never null, but tools built on EMF might not guarantee this fact. In
> our project, for example, we have to create context menus including
> above named actions for the currently selected element (EObject) in a
> tree viewer. Under certain condition, it happens, that the selected
> element is a proxy object, for which the actions are unable to
> retrieve an editing domain.
>
> An error dialog is shown after selecting these objects, so what I
> suggest is that these actions support the case when editing domain is
> null.
>
> What I have done is to override the createCommand(Collection<?>) of
> these action returning an UnexecutableCommand.INSTANCE when editing
> domain is null. see below the snippet :
>
> -----
> @Override
> public Command createCommand(Collection<?> selection) {
> if (domain != null) {
> return super.createCommand(selection);
> }
> return UnexecutableCommand.INSTANCE;
> }
> -----
>
> Thanks,
> Ali
>
> Ed Merks a
Re: EditingDomainActionBarContributor#init(IActionBars) [message #431286 is a reply to message #431281] Tue, 07 July 2009 14:56 Go to previous messageGo to next message
Ali Akar is currently offline Ali AkarFriend
Messages: 29
Registered: July 2009
Junior Member
I agree with you in case of editors which work either on one EObject (an
editor opened to edit an EObject) or one Resource , this works fine if
you have a good management of opened editors when unloading resources.
But, in my case, I'm using the common navigator framework, so my part
manages many meta-models and therefor many editing domains.


Ed Merks a écrit :
> Ali,
>
> Shouldn't the domain be determinable from the workbench part?
>
> public void setActiveWorkbenchPart(IWorkbenchPart workbenchPart)
> {
> if (workbenchPart instanceof IEditingDomainProvider)
> {
> domain =
> ((IEditingDomainProvider)workbenchPart).getEditingDomain();
> }
> }
>
>
> Ali Akar wrote:
>> Thanks Ed for your answer,
>>
>> I have just one more proposition, if it relevant !!
>>
>> The EMF Delete/Copy/Paste... actions expect that the editing domain is
>> never null, but tools built on EMF might not guarantee this fact. In
>> our project, for example, we have to create context menus including
>> above named actions for the currently selected element (EObject) in a
>> tree viewer. Under certain condition, it happens, that the selected
>> element is a proxy object, for which the actions are unable to
>> retrieve an editing domain.
>>
>> An error dialog is shown after selecting these objects, so what I
>> suggest is that these actions support the case when editing domain is
>> null.
>>
>> What I have done is to override the createCommand(Collection<?>) of
>> these action returning an UnexecutableCommand.INSTANCE when editing
>> domain is null. see below the snippet :
>>
>> -----
>> @Override
>> public Command createCommand(Collection<?> selection) {
>> if (domain != null) {
>> return super.createCommand(selection);
>> }
>> return UnexecutableCommand.INSTANCE;
>> }
>> -----
>>
>> Thanks,
>> Ali
>>
>> Ed Merks a écrit :
>>
>>> Ali,
>>>
>>> Yes, that does seem more flexible. Feel free to open a bugzilla.
>>>
>>>
>>> Ali Akar wrote:
>>>> Hi all,
>>>>
>>>> The Delete/Copy/Paste... actions are instantiated directly in the
>>>> init method ? I think, it would be better that each action is
>>>> created in an externalized method, something like this :
>>>>
>>>> deleteAction = CreateDeleteAction();
>>>>
>>>> It will be easiest to override this method instead of overriding the
>>>> init.
>>>>
>>>> I'm asking if its relevant to create an enhancement bug for this
>>>> issue ?
>>>>
>>>> Thanks for Ed and all EMF guys,
>>>> Ali
Re: EditingDomainActionBarContributor#init(IActionBars) [message #431287 is a reply to message #431286] Tue, 07 July 2009 15:00 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30687
Registered: July 2009
Senior Member
Ali,

I see, but I'm not generally happy making changes to fix problems that I
can't reproduce... For example, I don't even know what logic you use to
determine the editing domain when you can determine it. One might
provide an editing domain instance that always returns unexecutable
commands as a solution, for example...


Ali Akar wrote:
> I agree with you in case of editors which work either on one EObject
> (an editor opened to edit an EObject) or one Resource , this works
> fine if you have a good management of opened editors when unloading
> resources. But, in my case, I'm using the common navigator framework,
> so my part manages many meta-models and therefor many editing domains.
>
>
> Ed Merks a écrit :
>> Ali,
>>
>> Shouldn't the domain be determinable from the workbench part?
>>
>> public void setActiveWorkbenchPart(IWorkbenchPart workbenchPart)
>> {
>> if (workbenchPart instanceof IEditingDomainProvider)
>> {
>> domain =
>> ((IEditingDomainProvider)workbenchPart).getEditingDomain();
>> }
>> }
>>
>>
>> Ali Akar wrote:
>>> Thanks Ed for your answer,
>>>
>>> I have just one more proposition, if it relevant !!
>>>
>>> The EMF Delete/Copy/Paste... actions expect that the editing domain
>>> is never null, but tools built on EMF might not guarantee this fact.
>>> In our project, for example, we have to create context menus
>>> including above named actions for the currently selected element
>>> (EObject) in a tree viewer. Under certain condition, it happens,
>>> that the selected element is a proxy object, for which the actions
>>> are unable to retrieve an editing domain.
>>>
>>> An error dialog is shown after selecting these objects, so what I
>>> suggest is that these actions support the case when editing domain
>>> is null.
>>>
>>> What I have done is to override the createCommand(Collection<?>) of
>>> these action returning an UnexecutableCommand.INSTANCE when editing
>>> domain is null. see below the snippet :
>>>
>>> -----
>>> @Override
>>> public Command createCommand(Collection<?> selection) {
>>> if (domain != null) {
>>> return super.createCommand(selection);
>>> }
>>> return UnexecutableCommand.INSTANCE;
>>> }
>>> -----
>>>
>>> Thanks,
>>> Ali
>>>
>>> Ed Merks a écrit :
>>>
>>>> Ali,
>>>>
>>>> Yes, that does seem more flexible. Feel free to open a bugzilla.
>>>>
>>>>
>>>> Ali Akar wrote:
>>>>> Hi all,
>>>>>
>>>>> The Delete/Copy/Paste... actions are instantiated directly in the
>>>>> init method ? I think, it would be better that each action is
>>>>> created in an externalized method, something like this :
>>>>>
>>>>> deleteAction = CreateDeleteAction();
>>>>>
>>>>> It will be easiest to override this method instead of overriding
>>>>> the init.
>>>>>
>>>>> I'm asking if its relevant to create an enhancement bug for this
>>>>> issue ?
>>>>>
>>>>> Thanks for Ed and all EMF guys,
>>>>> Ali
Previous Topic:EStructuralFeature.isNullable()
Next Topic:[EMF Databinding] How to specify additional triggers for the update of a binding?
Goto Forum:
  


Current Time: Mon Dec 09 21:34:21 GMT 2019

Powered by FUDForum. Page generated in 0.02347 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top