Home » Modeling » EMF » EditingDomainActionBarContributor#init(IActionBars)
| EditingDomainActionBarContributor#init(IActionBars) [message #431274] |
Tue, 07 July 2009 05:54  |
Eclipse User |
|
|
|
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  |
| Eclipse User |
|
|
|
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 |
| Eclipse User |
|
|
|
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 |
| Eclipse User |
|
|
|
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 |
| Eclipse User |
|
|
|
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
|
|
|
Goto Forum:
Current Time: Mon Jul 07 10:53:43 EDT 2025
Powered by FUDForum. Page generated in 0.27301 seconds |
Home