Skip to main content



      Home
Home » Modeling » EMF » EditingDomainActionBarContributor#init(IActionBars)
EditingDomainActionBarContributor#init(IActionBars) [message #431274] Tue, 07 July 2009 05:54 Go to next message
Eclipse UserFriend
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 06:57 Go to previous messageGo to next message
Eclipse UserFriend
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 08:57 Go to previous messageGo to next message
Eclipse UserFriend
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 09:30 Go to previous messageGo to next message
Eclipse UserFriend
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 10:56 Go to previous messageGo to next message
Eclipse UserFriend
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 11:00 Go to previous message
Eclipse UserFriend
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 Jul 07 10:53:43 EDT 2025

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

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

Back to the top