Home » Modeling » EMF » invoke EOperation view
|
| Re: invoke EOperation view [message #539211 is a reply to message #539200] |
Thu, 10 June 2010 00:33   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
Hallvard Trætteberg wrote:
> Hi,
>
> Today I got an idea for a view, which I thought I'd present before
> starting the implementation. The problem I wish to "solve" is that the
> Ecore editor lacks a way of invoking EOperations. This is particularly
> relevant now that EMF supports annotating a model with script code and
> delegating to an engine.
Very true.
>
> The idea is as follows:
> - The new view contains a combo above a property sheet.
> - The view attaches to the active editor, if it implements
> EditingDomainProvider
> - When an EObject is selected, the view populates the combo box with
> all the EOperations that are defined for the EObject('s class).
> - When one of the EOperations are selected, it can be invoked by
> pressing an invoke button.
>
> The neat trick is how to provide arguments to the EOperation:
> - An EClass containing attributes and references corresponding to the
> EOperation's parameters is created.
> - An instance of this EClass is dynamically created.
> - The property sheet is set to display this dynamic instance, so the
> user may input the appropriate values.
> - The property values are collected in an EList and given to the
> EOperation's eInvoke method, which is called within a ChangeCommand.
>
> Two questions:
> - Does this design work?
Cool. I think it would.
> - Is it useful?
I think so. I suppose another approach would be to define it as an
action on the context menu that brings up a wizard, but that would
pollute a lot of context menus. Perhaps a generator option to add it to
the context menu would be better, as well as including it in the
reflective editor...
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: invoke EOperation view [message #539326 is a reply to message #539211] |
Thu, 10 June 2010 12:43 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I now have a prototype that work. The view picks up the selection (and
editing domain) from the active editor, populates a drop-down with
EOperations and the property sheet (page) lets the user edit the
parameters of the selected EOperation.
It was slightly more tricky than I thought. I had to create a container
object with a reference to the original selection, so that the item
provider used by the property sheet could find contextual objects.
Hence, there are a lot of Ecore objects involved in the final design:
- editor selection: EObject
- selected operation: EOperation
- dynamically created class and instance for operation's arguments (one
for each selected EOperation): EClass (containing EReferences and
EAttributes) and EObject
- dynamically created class (once) and instance for container of
arguments (references editor selection): EClass and EObject
How can this be contributed? I'm doing this in the context of JS4EMF,
but it's totally independent of it.
Hallvard
On 10.06.10 02.33, Ed Merks wrote:
> Hallvard,
>
> Comments below.
>
> Hallvard Trætteberg wrote:
>> Hi,
>>
>> Today I got an idea for a view, which I thought I'd present before
>> starting the implementation. The problem I wish to "solve" is that the
>> Ecore editor lacks a way of invoking EOperations. This is particularly
>> relevant now that EMF supports annotating a model with script code and
>> delegating to an engine.
> Very true.
>>
>> The idea is as follows:
>> - The new view contains a combo above a property sheet.
>> - The view attaches to the active editor, if it implements
>> EditingDomainProvider
>> - When an EObject is selected, the view populates the combo box with
>> all the EOperations that are defined for the EObject('s class).
>> - When one of the EOperations are selected, it can be invoked by
>> pressing an invoke button.
>>
>> The neat trick is how to provide arguments to the EOperation:
>> - An EClass containing attributes and references corresponding to the
>> EOperation's parameters is created.
>> - An instance of this EClass is dynamically created.
>> - The property sheet is set to display this dynamic instance, so the
>> user may input the appropriate values.
>> - The property values are collected in an EList and given to the
>> EOperation's eInvoke method, which is called within a ChangeCommand.
>>
>> Two questions:
>> - Does this design work?
> Cool. I think it would.
>> - Is it useful?
> I think so. I suppose another approach would be to define it as an
> action on the context menu that brings up a wizard, but that would
> pollute a lot of context menus. Perhaps a generator option to add it to
> the context menu would be better, as well as including it in the
> reflective editor...
>>
>> Hallvard
|
|
|
| Re: invoke EOperation view [message #539358 is a reply to message #539326] |
Thu, 10 June 2010 14:23 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
That sounds very cool. Let's open a bugzilla and attach it there. I
suppose invoking an operation could have a side-effect that might need
undo support. Do you think a view is better than a wizard/dialog? I'm
always a bit concerned about EMF introducing much of a visible presence
in the IDE...
Hallvard Trætteberg wrote:
> Hi,
>
> I now have a prototype that work. The view picks up the selection (and
> editing domain) from the active editor, populates a drop-down with
> EOperations and the property sheet (page) lets the user edit the
> parameters of the selected EOperation.
>
> It was slightly more tricky than I thought. I had to create a
> container object with a reference to the original selection, so that
> the item provider used by the property sheet could find contextual
> objects.
>
> Hence, there are a lot of Ecore objects involved in the final design:
>
> - editor selection: EObject
> - selected operation: EOperation
> - dynamically created class and instance for operation's arguments
> (one for each selected EOperation): EClass (containing EReferences and
> EAttributes) and EObject
> - dynamically created class (once) and instance for container of
> arguments (references editor selection): EClass and EObject
>
> How can this be contributed? I'm doing this in the context of JS4EMF,
> but it's totally independent of it.
>
> Hallvard
>
> On 10.06.10 02.33, Ed Merks wrote:
>> Hallvard,
>>
>> Comments below.
>>
>> Hallvard Trætteberg wrote:
>>> Hi,
>>>
>>> Today I got an idea for a view, which I thought I'd present before
>>> starting the implementation. The problem I wish to "solve" is that the
>>> Ecore editor lacks a way of invoking EOperations. This is particularly
>>> relevant now that EMF supports annotating a model with script code and
>>> delegating to an engine.
>> Very true.
>>>
>>> The idea is as follows:
>>> - The new view contains a combo above a property sheet.
>>> - The view attaches to the active editor, if it implements
>>> EditingDomainProvider
>>> - When an EObject is selected, the view populates the combo box with
>>> all the EOperations that are defined for the EObject('s class).
>>> - When one of the EOperations are selected, it can be invoked by
>>> pressing an invoke button.
>>>
>>> The neat trick is how to provide arguments to the EOperation:
>>> - An EClass containing attributes and references corresponding to the
>>> EOperation's parameters is created.
>>> - An instance of this EClass is dynamically created.
>>> - The property sheet is set to display this dynamic instance, so the
>>> user may input the appropriate values.
>>> - The property values are collected in an EList and given to the
>>> EOperation's eInvoke method, which is called within a ChangeCommand.
>>>
>>> Two questions:
>>> - Does this design work?
>> Cool. I think it would.
>>> - Is it useful?
>> I think so. I suppose another approach would be to define it as an
>> action on the context menu that brings up a wizard, but that would
>> pollute a lot of context menus. Perhaps a generator option to add it to
>> the context menu would be better, as well as including it in the
>> reflective editor...
>>>
>>> Hallvard
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: invoke EOperation view [message #539574 is a reply to message #539358] |
Fri, 11 June 2010 11:13 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 10.06.10 16.23, Ed Merks wrote:
>
> That sounds very cool. Let's open a bugzilla and attach it there.
Here it is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=316588
> I suppose invoking an operation could have a side-effect that might need
> undo support.
The EOperation is invoked within a ChangeCommand using the editor's
editing domain, and this should give undo support (in the editor, not in
the view).
> Do you think a view is better than a wizard/dialog? I'm
> always a bit concerned about EMF introducing much of a visible presence
> in the IDE...
I like views better than dialogs, since they may also show relevant
information, like if there actually are EOperations for en EObject. The
prototype is designed so that it is easy to invoke the same EOperation
with the same arguments on an EObject of the same EClass, since in this
case the combo and property sheet is not reset. Repetitive invocations
become very hard if you need to use the context menu and bring up a dialog.
I can imagine a related view could be relevant: Replace the property
sheet with a multi-line text field, for browsing and potentially editing
the script source. This should make writing, testing and using scripts a
lot easier. For this to work, it would have to be supported to change
the EOperation annnotations of a static class (and have it affect
subsequent eInvokes.
Hallvard
|
|
|
Goto Forum:
Current Time: Sat Apr 27 03:36:01 GMT 2024
Powered by FUDForum. Page generated in 0.03497 seconds |
] 
Search
Help
Register
Login
Home
