Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [Ecore Tools Proposal] feedback
| [Ecore Tools Proposal] feedback [message #101025] |
Wed, 07 November 2007 10:32  |
 Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Hi,
I was looking for a graphical Ecore editor. Ed Merks told me to have a
look at the Ecore Tools proposal.
Here are some needs (requirements) for such an editor:
1) Be able to add dependencies to models located either in workspace or in
target platform (as the Load resource from the Sample Ecore editor).
2) Multi-diagram support, navigation between diagrams and sub-diagrams.
2bis) Multi packages support with navigation in their related diagrams.
3) Diagrams serialized in their own files independent from the ecore ones.
4) GMF L&F.
5) Be able to open diagrams located either in workspace or in target
platform (ie use URIEditorInput rather than FileEditorInput)
6) Export diagrams in different image formats : GIF, PNG, SVG,...
7) "Delete from diagram" & "Delete from model" features.
8) Initialize a diagram content from an existing ecore (Improvement of the
Topcased initialization algorithm would be appreciated, eUML2 does better
that)
9) Have the possibility to hide (or show) some diagram parts :
relationships between metaclasses by type (association, aggregation...),
attributes...
I know that most of these needs are already fulfilled by Topcased Ecore
editor.
Hope it helps,
Stephane.
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #101057 is a reply to message #101025] |
Wed, 07 November 2007 11:17  |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi,
I have a question (not sure if it'd be better asked onthe GMF newsgroup):
Will the new Ecore Designer be strongly coupled to the
Transaction&Workspace plugins?
And an additional requirement:
Creation and modifiction of bidirectional references should be easy
(easier than handling both ends separately).
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Stephane schrieb:
> Hi,
>
> I was looking for a graphical Ecore editor. Ed Merks told me to have a
> look at the Ecore Tools proposal.
>
> Here are some needs (requirements) for such an editor:
> 1) Be able to add dependencies to models located either in workspace
> or in target platform (as the Load resource from the Sample Ecore
> editor).
>
> 2) Multi-diagram support, navigation between diagrams and sub-diagrams.
> 2bis) Multi packages support with navigation in their related diagrams.
>
> 3) Diagrams serialized in their own files independent from the ecore
> ones.
>
> 4) GMF L&F.
>
> 5) Be able to open diagrams located either in workspace or in target
> platform (ie use URIEditorInput rather than FileEditorInput)
>
> 6) Export diagrams in different image formats : GIF, PNG, SVG,...
>
> 7) "Delete from diagram" & "Delete from model" features.
>
> 8) Initialize a diagram content from an existing ecore (Improvement of
> the Topcased initialization algorithm would be appreciated, eUML2 does
> better that)
>
> 9) Have the possibility to hide (or show) some diagram parts :
> relationships between metaclasses by type (association,
> aggregation...), attributes...
>
> I know that most of these needs are already fulfilled by Topcased
> Ecore editor.
>
> Hope it helps,
> Stephane.
>
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #101085 is a reply to message #101025] |
Wed, 07 November 2007 14:21 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Stephane,
Comments below.
Stephane wrote:
> Hi,
>
> I was looking for a graphical Ecore editor. Ed Merks told me to have a
> look at the Ecore Tools proposal.
>
> Here are some needs (requirements) for such an editor:
> 1) Be able to add dependencies to models located either in workspace
> or in target platform (as the Load resource from the Sample Ecore
> editor).
This should be trivial to support.
>
> 2) Multi-diagram support, navigation between diagrams and sub-diagrams.
I believe this is there.
> 2bis) Multi packages support with navigation in their related diagrams.
I think this is too.
>
> 3) Diagrams serialized in their own files independent from the ecore
> ones.
I'm sure this is supported.
>
> 4) GMF L&F.
It's based on GMF, so this must be the case.
>
> 5) Be able to open diagrams located either in workspace or in target
> platform (ie use URIEditorInput rather than FileEditorInput)
Likely this is just a matter of the Diagrams being available in the
binary plugins. After all, platform:/plugin/<plugin-id>/... will load
from an installed plugin, so that should work reasonably the same way
loading Ecore or GenModels work. I'm not sure what mechanism would be
used to actually open an editor directly for that though. The IDE
doesn't have an "Open URI" action...
>
> 6) Export diagrams in different image formats : GIF, PNG, SVG,...
I assume this is provided by GMF. Whatever GMF provides should end up
being surfaced.
>
> 7) "Delete from diagram" & "Delete from model" features.
Yes, I would need this too.
>
> 8) Initialize a diagram content from an existing ecore (Improvement of
> the Topcased initialization algorithm would be appreciated, eUML2 does
> better that)
I already tried this and it worked. I've never tried eUML2.
>
> 9) Have the possibility to hide (or show) some diagram parts :
> relationships between metaclasses by type (association,
> aggregation...), attributes...
You mean a dynamic filter capability as opposed to deleting them from
the diagram?
>
> I know that most of these needs are already fulfilled by Topcased
> Ecore editor.
This editor is already looking very good to me. Did you try installing
it. The code base was approved to be committed to CVS yesterday and we
plan to help David with setting up builds. It's so exciting!
>
> Hope it helps,
> Stephane.
>
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #101099 is a reply to message #101057] |
Wed, 07 November 2007 14:24 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Eike,
I assume so since this is part of the framework that GMF generally
relies upon. I'm not totally happy about bidirectional references
being rendered as two separate lines. I kind of like the UML notation
where it's a single line with two ends. I don't know enough about GMF
yet to know if this is just a hard thing to accomplish. I want to help
add support for generics too. I know David and company can't simply
implement everything we want and ask for...
Eike Stepper wrote:
> Hi,
>
> I have a question (not sure if it'd be better asked onthe GMF newsgroup):
> Will the new Ecore Designer be strongly coupled to the
> Transaction&Workspace plugins?
>
> And an additional requirement:
> Creation and modifiction of bidirectional references should be easy
> (easier than handling both ends separately).
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
>
> Stephane schrieb:
>> Hi,
>>
>> I was looking for a graphical Ecore editor. Ed Merks told me to have
>> a look at the Ecore Tools proposal.
>>
>> Here are some needs (requirements) for such an editor:
>> 1) Be able to add dependencies to models located either in workspace
>> or in target platform (as the Load resource from the Sample Ecore
>> editor).
>>
>> 2) Multi-diagram support, navigation between diagrams and sub-diagrams.
>> 2bis) Multi packages support with navigation in their related diagrams.
>>
>> 3) Diagrams serialized in their own files independent from the ecore
>> ones.
>>
>> 4) GMF L&F.
>>
>> 5) Be able to open diagrams located either in workspace or in target
>> platform (ie use URIEditorInput rather than FileEditorInput)
>>
>> 6) Export diagrams in different image formats : GIF, PNG, SVG,...
>>
>> 7) "Delete from diagram" & "Delete from model" features.
>>
>> 8) Initialize a diagram content from an existing ecore (Improvement
>> of the Topcased initialization algorithm would be appreciated, eUML2
>> does better that)
>>
>> 9) Have the possibility to hide (or show) some diagram parts :
>> relationships between metaclasses by type (association,
>> aggregation...), attributes...
>>
>> I know that most of these needs are already fulfilled by Topcased
>> Ecore editor.
>>
>> Hope it helps,
>> Stephane.
>>
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #101111 is a reply to message #101099] |
Wed, 07 November 2007 14:38 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Ed Merks schrieb:
> Eike,
>
> I assume so since this is part of the framework that GMF generally
> relies upon. I'm not totally happy about bidirectional references
> being rendered as two separate lines. I kind of like the UML notation
> where it's a single line with two ends. I don't know enough about GMF
> yet to know if this is just a hard thing to accomplish. I want to
> help add support for generics too. I know David and company can't
> simply implement everything we want and ask for...
That's clear but they will want to know about ;-)
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
>
>
> Eike Stepper wrote:
>> Hi,
>>
>> I have a question (not sure if it'd be better asked onthe GMF
>> newsgroup):
>> Will the new Ecore Designer be strongly coupled to the
>> Transaction&Workspace plugins?
>>
>> And an additional requirement:
>> Creation and modifiction of bidirectional references should be easy
>> (easier than handling both ends separately).
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>>
>> Stephane schrieb:
>>> Hi,
>>>
>>> I was looking for a graphical Ecore editor. Ed Merks told me to have
>>> a look at the Ecore Tools proposal.
>>>
>>> Here are some needs (requirements) for such an editor:
>>> 1) Be able to add dependencies to models located either in workspace
>>> or in target platform (as the Load resource from the Sample Ecore
>>> editor).
>>>
>>> 2) Multi-diagram support, navigation between diagrams and sub-diagrams.
>>> 2bis) Multi packages support with navigation in their related diagrams.
>>>
>>> 3) Diagrams serialized in their own files independent from the ecore
>>> ones.
>>>
>>> 4) GMF L&F.
>>>
>>> 5) Be able to open diagrams located either in workspace or in target
>>> platform (ie use URIEditorInput rather than FileEditorInput)
>>>
>>> 6) Export diagrams in different image formats : GIF, PNG, SVG,...
>>>
>>> 7) "Delete from diagram" & "Delete from model" features.
>>>
>>> 8) Initialize a diagram content from an existing ecore (Improvement
>>> of the Topcased initialization algorithm would be appreciated, eUML2
>>> does better that)
>>>
>>> 9) Have the possibility to hide (or show) some diagram parts :
>>> relationships between metaclasses by type (association,
>>> aggregation...), attributes...
>>>
>>> I know that most of these needs are already fulfilled by Topcased
>>> Ecore editor.
>>>
>>> Hope it helps,
>>> Stephane.
>>>
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #101261 is a reply to message #101085] |
Wed, 07 November 2007 22:53 |
Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Hi, Ed,
Comments below.
Ed Merks wrote:
> Stephane,
>
> Comments below.
>
>
> Stephane wrote:
>> Hi,
>>
>> I was looking for a graphical Ecore editor. Ed Merks told me to have a
>> look at the Ecore Tools proposal.
>>
>> Here are some needs (requirements) for such an editor:
>> 1) Be able to add dependencies to models located either in workspace
>> or in target platform (as the Load resource from the Sample Ecore
>> editor).
> This should be trivial to support.
Now, in Topcased, to add a dependency to a model hosted by a plug-in in
the target platform, you have to enter the path by hand like
platform:/plugin/<plugin-id>/model/myModel.ecore.
The "Load resource dialog" only offers 2 load options : "browse from
workspace" or "browse from file system". It can be enhanced in reusing
the one from the EMF Ecore editor, that offers a 3rd load option "Browse
from registered packages".
>>
>> 2) Multi-diagram support, navigation between diagrams and sub-diagrams.
> I believe this is there.
>> 2bis) Multi packages support with navigation in their related diagrams.
> I think this is too.
It perfectly works with Topcased.
>>
>> 3) Diagrams serialized in their own files independent from the ecore
>> ones.
> I'm sure this is supported.
Indeed.
>>
>> 4) GMF L&F.
> It's based on GMF, so this must be the case.
I'm not sure to have the popup menu that appears on diagram to create
model elements as in the GMF-based example ? (It's not important)
>>
>> 5) Be able to open diagrams located either in workspace or in target
>> platform (ie use URIEditorInput rather than FileEditorInput)
> Likely this is just a matter of the Diagrams being available in the
> binary plugins. After all, platform:/plugin/<plugin-id>/... will load
> from an installed plugin, so that should work reasonably the same way
> loading Ecore or GenModels work. I'm not sure what mechanism would be
> used to actually open an editor directly for that though. The IDE
> doesn't have an "Open URI" action...
>>
I agree with you.
At the moment, if I'am right, Topcased Ecore editor
only handles FileInputEditor. I'am sure, it's not a big issue to move to
URIEditorInput as you did in the Ecore2Ecore editor.
In JDT or PDE, there are some JarEditorInput (internal API) to be able
to open files included in jared plug-ins (e.g it's used to open
plugin.xml or MANIFEST.MF). But from my point of view, it is simpler to
use an URIEditorInput.
>> 6) Export diagrams in different image formats : GIF, PNG, SVG,...
> I assume this is provided by GMF. Whatever GMF provides should end up
> being surfaced.
>>
>> 7) "Delete from diagram" & "Delete from model" features.
> Yes, I would need this too.
>>
>> 8) Initialize a diagram content from an existing ecore (Improvement of
>> the Topcased initialization algorithm would be appreciated, eUML2 does
>> better that)
> I already tried this and it worked. I've never tried eUML2.
Try with the Library model provided in EMF tutorial, and you will get a
diagram where connections betweens model elements are in all directions.
Not easy to read and to re-arrange.
eUML2 layouts model elements in different layers (top to bottom) that
are driven by inheritance between classes.
From my point of view, it's a good idea, and the diagram is clearer to
read.
>>
>> 9) Have the possibility to hide (or show) some diagram parts :
>> relationships between metaclasses by type (association,
>> aggregation...), attributes...
> You mean a dynamic filter capability as opposed to deleting them from
> the diagram?
Yes, a dynamic filter capability, it allows the end-user to get a
diagram showing only classes and inheritance or classes with association
relationships, or abstract classes or whatever....
It is a usual capability in GIS software like in Google Earth where you
can display or not buildings, roads, restaurants,...
>>
>> I know that most of these needs are already fulfilled by Topcased
>> Ecore editor.
> This editor is already looking very good to me. Did you try installing
> it. The code base was approved to be committed to CVS yesterday and we
> plan to help David with setting up builds. It's so exciting!
Yes, I install it and integrate it in the software I am working on. It's
the "Ecore editor" to design business models.
It would be a pleasure to download the future Ecore Tools builds to test
it and report potential issues.
A last suggestion, when you are designing a big model, it could be
useful to have such features:
"show in diagram" from a selected element in the outline.
"show in outline" from a selected element in the diagram.
It allows the end-user to easily retrieve its model elements. If you are
not the one who designed a model, it helps to navigate in its contained
elements.
>>
>> Hope it helps,
>> Stephane.
>>
--
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #101276 is a reply to message #101261] |
Thu, 08 November 2007 07:29 |
David Sciamma
Messages: 78
Registered: July 2009 |
Member |
|
|
Hi,
Thank you all for your feedback, we will try to implement the best Ecore
Editor we can do.
Comments below.
Stéphane Fournier a écrit :
> Hi, Ed,
> Comments below.
>
> Ed Merks wrote:
>> Stephane,
>>
>> Comments below.
>>
>>
>> Stephane wrote:
>>> Hi,
>>>
>>> I was looking for a graphical Ecore editor. Ed Merks told me to have
>>> a look at the Ecore Tools proposal.
>>>
>>> Here are some needs (requirements) for such an editor:
>>> 1) Be able to add dependencies to models located either in workspace
>>> or in target platform (as the Load resource from the Sample Ecore
>>> editor).
>> This should be trivial to support.
>
> Now, in Topcased, to add a dependency to a model hosted by a plug-in in
> the target platform, you have to enter the path by hand like
> platform:/plugin/<plugin-id>/model/myModel.ecore.
> The "Load resource dialog" only offers 2 load options : "browse from
> workspace" or "browse from file system". It can be enhanced in reusing
> the one from the EMF Ecore editor, that offers a 3rd load option "Browse
> from registered packages".
In Topcased, we added an item in the Outline called "Registered Package"
to be able to import objects. In a first implementation we will reuse
the dialog from EMF Ecore Editor.
>
>>>
>>> 2) Multi-diagram support, navigation between diagrams and sub-diagrams.
>> I believe this is there.
>>> 2bis) Multi packages support with navigation in their related diagrams.
>> I think this is too.
> It perfectly works with Topcased.
Multi-diagram must still be improved in GMF.
>>>
>>> 3) Diagrams serialized in their own files independent from the ecore
>>> ones.
>> I'm sure this is supported.
> Indeed.
>>>
>>> 4) GMF L&F.
>> It's based on GMF, so this must be the case.
> I'm not sure to have the popup menu that appears on diagram to create
> model elements as in the GMF-based example ? (It's not important)
>>>
>>> 5) Be able to open diagrams located either in workspace or in target
>>> platform (ie use URIEditorInput rather than FileEditorInput)
>> Likely this is just a matter of the Diagrams being available in the
>> binary plugins. After all, platform:/plugin/<plugin-id>/... will load
>> from an installed plugin, so that should work reasonably the same way
>> loading Ecore or GenModels work. I'm not sure what mechanism would be
>> used to actually open an editor directly for that though. The IDE
>> doesn't have an "Open URI" action...
We will reuse implementation from GMF and not from Topcased for this
mechanism.
>>>
> I agree with you.
> At the moment, if I'am right, Topcased Ecore editor
> only handles FileInputEditor. I'am sure, it's not a big issue to move to
> URIEditorInput as you did in the Ecore2Ecore editor.
> In JDT or PDE, there are some JarEditorInput (internal API) to be able
> to open files included in jared plug-ins (e.g it's used to open
> plugin.xml or MANIFEST.MF). But from my point of view, it is simpler to
> use an URIEditorInput.
>
>>> 6) Export diagrams in different image formats : GIF, PNG, SVG,...
>> I assume this is provided by GMF. Whatever GMF provides should end up
>> being surfaced.
>>>
>>> 7) "Delete from diagram" & "Delete from model" features.
>> Yes, I would need this too.
It is a major requirement for us too
>>>
>>> 8) Initialize a diagram content from an existing ecore (Improvement
>>> of the Topcased initialization algorithm would be appreciated, eUML2
>>> does better that)
>> I already tried this and it worked. I've never tried eUML2.
> Try with the Library model provided in EMF tutorial, and you will get a
> diagram where connections betweens model elements are in all directions.
> Not easy to read and to re-arrange.
> eUML2 layouts model elements in different layers (top to bottom) that
> are driven by inheritance between classes.
> From my point of view, it's a good idea, and the diagram is clearer to
> read.
Soyatec (eUML2 developers) is interested in the Ecore Tools Component so
perhaps it could be a first external contribution :)
>
>>>
>>> 9) Have the possibility to hide (or show) some diagram parts :
>>> relationships between metaclasses by type (association,
>>> aggregation...), attributes...
>> You mean a dynamic filter capability as opposed to deleting them from
>> the diagram?
> Yes, a dynamic filter capability, it allows the end-user to get a
> diagram showing only classes and inheritance or classes with association
> relationships, or abstract classes or whatever....
> It is a usual capability in GIS software like in Google Earth where you
> can display or not buildings, roads, restaurants,...
We have develop a first solution for another GMF editor and we are
working on its "generalization"
>
>
>>>
>>> I know that most of these needs are already fulfilled by Topcased
>>> Ecore editor.
>> This editor is already looking very good to me. Did you try
>> installing it. The code base was approved to be committed to CVS
>> yesterday and we plan to help David with setting up builds. It's so
>> exciting!
>
> Yes, I install it and integrate it in the software I am working on. It's
> the "Ecore editor" to design business models.
>
> It would be a pleasure to download the future Ecore Tools builds to test
> it and report potential issues.
>
> A last suggestion, when you are designing a big model, it could be
> useful to have such features:
> "show in diagram" from a selected element in the outline.
> "show in outline" from a selected element in the diagram.
> It allows the end-user to easily retrieve its model elements. If you are
> not the one who designed a model, it helps to navigate in its contained
> elements.
>
We plan to implement a "Link with editor"-like mechanism (a toggle
button on the outline) doing this like the package editor do for Java
objects.
>>>
>>> Hope it helps,
>>> Stephane.
>>>
>
Sure it will help,
--
David SCIAMMA
Expert Eclipse / Eclipse Expert
ANYWARE TECHNOLOGIES
Tel : + 33 (0)5.61.00.73.44
Fax : + 33 (0)5.61.00.51.46
http://www.anyware-tech.com
|
|
| |
| Re: [Ecore Tools Proposal] feedback [message #101994 is a reply to message #101980] |
Thu, 08 November 2007 17:56 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------020408090201000806070301
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Felix,
I don't want to put words in peoples mouths, but I assume that if you do
"Delete from model" the object is deleted from the .ecore and that this
also deletes all references to this object and anything associated with
those references (in coming and outgoing arrows), while "Delete from
Diagram" just says, leave my model alone, I just don't want to see this
thing in this particular diagram because this diagram is a view and I
don't want it to be a view of everything at once...
Felix Dorner wrote:
> Hi,
>
>
>>>>> 7) "Delete from diagram" & "Delete from model" features.
>>>>>
>>>> Yes, I would need this too.
>>>>
>> It is a major requirement for us too
>>
>
> Can you explain this further? I´m sure I am misunderstanding: You´ d
> like to delete an element from the model and keep it in the diagram and
> the inverse? Does this mean you want to sync model and diagram files by
> hand?
>
> What until now was keeping me from the old topcased editor and also the
> one provided by gmf was the fear of a desynced relation between the
> model and the diagram, which indeed happend with the gmf editor. I
> understand that one might want to hide some elements from the diagram
> that exist in the model though.
>
> Felix
>
--------------020408090201000806070301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Felix,<br>
<br>
I don't want to put words in peoples mouths, but I assume that if you
do "Delete from model" the object is deleted from the .ecore and that
this also deletes all references to this object and anything associated
with those references (in coming and outgoing arrows), while "Delete
from Diagram" just says, leave my model alone, I just don't want to see
this thing in this particular diagram because this diagram is a view
and I don't want it to be a view of everything at once...<br>
<br>
<br>
Felix Dorner wrote:
<blockquote cite="mid:fgvf2c$mb9$1@build.eclipse.org" type="cite">
<pre wrap="">Hi,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">7) "Delete from diagram" & "Delete from model" features.
</pre>
</blockquote>
<pre wrap="">Yes, I would need this too.
</pre>
</blockquote>
</blockquote>
<pre wrap="">It is a major requirement for us too
</pre>
</blockquote>
<pre wrap=""><!---->
Can you explain this further? I´m sure I am misunderstanding: You´ d
like to delete an element from the model and keep it in the diagram and
the inverse? Does this mean you want to sync model and diagram files by
hand?
What until now was keeping me from the old topcased editor and also the
one provided by gmf was the fear of a desynced relation between the
model and the diagram, which indeed happend with the gmf editor. I
understand that one might want to hide some elements from the diagram
that exist in the model though.
Felix
</pre>
</blockquote>
<br>
</body>
</html>
--------------020408090201000806070301--
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #102207 is a reply to message #101994] |
Fri, 09 November 2007 13:42 |
Ed Willink
Messages: 7665
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> I don't want to put words in peoples mouths, but I assume that if you do
> "Delete from model" the object is deleted from the .ecore and that this
> also deletes all references to this object and anything associated with
> those references (in coming and outgoing arrows), while "Delete from
> Diagram" just says, leave my model alone, I just don't want to see this
> thing in this particular diagram because this diagram is a view and I
> don't want it to be a view of everything at once...
Hi Ed. Exactly my interpretation too. In my second attempt at a UMLX
editor I found that this ergonomic distinction is much more widespread.
A surprising number of edits that can be performed on a diagram/view can
also be differently be performed on the underlying (Ecore) model.
For instance:
Reconnect: ie. drag connection end from one node to another can be:
Reconnect-in-model, which is change EReference.eType and fix-up all diagrams,
or Reconnect-in-diagram, which is delete previous EReference instantiation
and create new EReference instantiation leaving the model unchanged, the
view just shows a different element from the model.
Instantiate: ie. drag an outline/navigator element into the diagram can be:
Create-in-model, which is create a new EClass or whatever, or
Create-in-diagram, which is display an additional element from the model
in the diagram.
With numerous commands having diagram/model alternatives it is helpful
to use a consistent keying: In EDiagram Bugzilla 106208 I suggested
XXX for XXX-in-diagram and CTRL-XXX as XXX-in-model etc.
When I implemented this myself, I found the need to CTRL-XXX to do Ecore
edits was a bit surprising and irritating, however not imposing a consistent
policy makes it difficult to support both forms of edit consistently.
However (Bugzilla 107367), the 'CTRL' key needs careful choice since
the more obvious Shift+DEL is a standard Eclipse equivalent for CUT.
The 'In-Model' 'shift' key must be available to uniformly qualify a variety
of keystokes.
Regards
Ed Willink
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #610272 is a reply to message #101025] |
Wed, 07 November 2007 11:17 |
|
Hi,
I have a question (not sure if it'd be better asked onthe GMF newsgroup):
Will the new Ecore Designer be strongly coupled to the
Transaction&Workspace plugins?
And an additional requirement:
Creation and modifiction of bidirectional references should be easy
(easier than handling both ends separately).
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Stephane schrieb:
> Hi,
>
> I was looking for a graphical Ecore editor. Ed Merks told me to have a
> look at the Ecore Tools proposal.
>
> Here are some needs (requirements) for such an editor:
> 1) Be able to add dependencies to models located either in workspace
> or in target platform (as the Load resource from the Sample Ecore
> editor).
>
> 2) Multi-diagram support, navigation between diagrams and sub-diagrams.
> 2bis) Multi packages support with navigation in their related diagrams.
>
> 3) Diagrams serialized in their own files independent from the ecore
> ones.
>
> 4) GMF L&F.
>
> 5) Be able to open diagrams located either in workspace or in target
> platform (ie use URIEditorInput rather than FileEditorInput)
>
> 6) Export diagrams in different image formats : GIF, PNG, SVG,...
>
> 7) "Delete from diagram" & "Delete from model" features.
>
> 8) Initialize a diagram content from an existing ecore (Improvement of
> the Topcased initialization algorithm would be appreciated, eUML2 does
> better that)
>
> 9) Have the possibility to hide (or show) some diagram parts :
> relationships between metaclasses by type (association,
> aggregation...), attributes...
>
> I know that most of these needs are already fulfilled by Topcased
> Ecore editor.
>
> Hope it helps,
> Stephane.
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #610277 is a reply to message #101025] |
Wed, 07 November 2007 14:21 |
Ed Merks
Messages: 33188
Registered: July 2009 |
Senior Member |
|
|
Stephane,
Comments below.
Stephane wrote:
> Hi,
>
> I was looking for a graphical Ecore editor. Ed Merks told me to have a
> look at the Ecore Tools proposal.
>
> Here are some needs (requirements) for such an editor:
> 1) Be able to add dependencies to models located either in workspace
> or in target platform (as the Load resource from the Sample Ecore
> editor).
This should be trivial to support.
>
> 2) Multi-diagram support, navigation between diagrams and sub-diagrams.
I believe this is there.
> 2bis) Multi packages support with navigation in their related diagrams.
I think this is too.
>
> 3) Diagrams serialized in their own files independent from the ecore
> ones.
I'm sure this is supported.
>
> 4) GMF L&F.
It's based on GMF, so this must be the case.
>
> 5) Be able to open diagrams located either in workspace or in target
> platform (ie use URIEditorInput rather than FileEditorInput)
Likely this is just a matter of the Diagrams being available in the
binary plugins. After all, platform:/plugin/<plugin-id>/... will load
from an installed plugin, so that should work reasonably the same way
loading Ecore or GenModels work. I'm not sure what mechanism would be
used to actually open an editor directly for that though. The IDE
doesn't have an "Open URI" action...
>
> 6) Export diagrams in different image formats : GIF, PNG, SVG,...
I assume this is provided by GMF. Whatever GMF provides should end up
being surfaced.
>
> 7) "Delete from diagram" & "Delete from model" features.
Yes, I would need this too.
>
> 8) Initialize a diagram content from an existing ecore (Improvement of
> the Topcased initialization algorithm would be appreciated, eUML2 does
> better that)
I already tried this and it worked. I've never tried eUML2.
>
> 9) Have the possibility to hide (or show) some diagram parts :
> relationships between metaclasses by type (association,
> aggregation...), attributes...
You mean a dynamic filter capability as opposed to deleting them from
the diagram?
>
> I know that most of these needs are already fulfilled by Topcased
> Ecore editor.
This editor is already looking very good to me. Did you try installing
it. The code base was approved to be committed to CVS yesterday and we
plan to help David with setting up builds. It's so exciting!
>
> Hope it helps,
> Stephane.
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #610281 is a reply to message #101057] |
Wed, 07 November 2007 14:24 |
Ed Merks
Messages: 33188
Registered: July 2009 |
Senior Member |
|
|
Eike,
I assume so since this is part of the framework that GMF generally
relies upon. I'm not totally happy about bidirectional references
being rendered as two separate lines. I kind of like the UML notation
where it's a single line with two ends. I don't know enough about GMF
yet to know if this is just a hard thing to accomplish. I want to help
add support for generics too. I know David and company can't simply
implement everything we want and ask for...
Eike Stepper wrote:
> Hi,
>
> I have a question (not sure if it'd be better asked onthe GMF newsgroup):
> Will the new Ecore Designer be strongly coupled to the
> Transaction&Workspace plugins?
>
> And an additional requirement:
> Creation and modifiction of bidirectional references should be easy
> (easier than handling both ends separately).
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
>
> Stephane schrieb:
>> Hi,
>>
>> I was looking for a graphical Ecore editor. Ed Merks told me to have
>> a look at the Ecore Tools proposal.
>>
>> Here are some needs (requirements) for such an editor:
>> 1) Be able to add dependencies to models located either in workspace
>> or in target platform (as the Load resource from the Sample Ecore
>> editor).
>>
>> 2) Multi-diagram support, navigation between diagrams and sub-diagrams.
>> 2bis) Multi packages support with navigation in their related diagrams.
>>
>> 3) Diagrams serialized in their own files independent from the ecore
>> ones.
>>
>> 4) GMF L&F.
>>
>> 5) Be able to open diagrams located either in workspace or in target
>> platform (ie use URIEditorInput rather than FileEditorInput)
>>
>> 6) Export diagrams in different image formats : GIF, PNG, SVG,...
>>
>> 7) "Delete from diagram" & "Delete from model" features.
>>
>> 8) Initialize a diagram content from an existing ecore (Improvement
>> of the Topcased initialization algorithm would be appreciated, eUML2
>> does better that)
>>
>> 9) Have the possibility to hide (or show) some diagram parts :
>> relationships between metaclasses by type (association,
>> aggregation...), attributes...
>>
>> I know that most of these needs are already fulfilled by Topcased
>> Ecore editor.
>>
>> Hope it helps,
>> Stephane.
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #610282 is a reply to message #101099] |
Wed, 07 November 2007 14:38 |
|
Ed Merks schrieb:
> Eike,
>
> I assume so since this is part of the framework that GMF generally
> relies upon. I'm not totally happy about bidirectional references
> being rendered as two separate lines. I kind of like the UML notation
> where it's a single line with two ends. I don't know enough about GMF
> yet to know if this is just a hard thing to accomplish. I want to
> help add support for generics too. I know David and company can't
> simply implement everything we want and ask for...
That's clear but they will want to know about ;-)
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
>
>
> Eike Stepper wrote:
>> Hi,
>>
>> I have a question (not sure if it'd be better asked onthe GMF
>> newsgroup):
>> Will the new Ecore Designer be strongly coupled to the
>> Transaction&Workspace plugins?
>>
>> And an additional requirement:
>> Creation and modifiction of bidirectional references should be easy
>> (easier than handling both ends separately).
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>>
>> Stephane schrieb:
>>> Hi,
>>>
>>> I was looking for a graphical Ecore editor. Ed Merks told me to have
>>> a look at the Ecore Tools proposal.
>>>
>>> Here are some needs (requirements) for such an editor:
>>> 1) Be able to add dependencies to models located either in workspace
>>> or in target platform (as the Load resource from the Sample Ecore
>>> editor).
>>>
>>> 2) Multi-diagram support, navigation between diagrams and sub-diagrams.
>>> 2bis) Multi packages support with navigation in their related diagrams.
>>>
>>> 3) Diagrams serialized in their own files independent from the ecore
>>> ones.
>>>
>>> 4) GMF L&F.
>>>
>>> 5) Be able to open diagrams located either in workspace or in target
>>> platform (ie use URIEditorInput rather than FileEditorInput)
>>>
>>> 6) Export diagrams in different image formats : GIF, PNG, SVG,...
>>>
>>> 7) "Delete from diagram" & "Delete from model" features.
>>>
>>> 8) Initialize a diagram content from an existing ecore (Improvement
>>> of the Topcased initialization algorithm would be appreciated, eUML2
>>> does better that)
>>>
>>> 9) Have the possibility to hide (or show) some diagram parts :
>>> relationships between metaclasses by type (association,
>>> aggregation...), attributes...
>>>
>>> I know that most of these needs are already fulfilled by Topcased
>>> Ecore editor.
>>>
>>> Hope it helps,
>>> Stephane.
>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #610294 is a reply to message #101085] |
Wed, 07 November 2007 22:53 |
Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Hi, Ed,
Comments below.
Ed Merks wrote:
> Stephane,
>
> Comments below.
>
>
> Stephane wrote:
>> Hi,
>>
>> I was looking for a graphical Ecore editor. Ed Merks told me to have a
>> look at the Ecore Tools proposal.
>>
>> Here are some needs (requirements) for such an editor:
>> 1) Be able to add dependencies to models located either in workspace
>> or in target platform (as the Load resource from the Sample Ecore
>> editor).
> This should be trivial to support.
Now, in Topcased, to add a dependency to a model hosted by a plug-in in
the target platform, you have to enter the path by hand like
platform:/plugin/<plugin-id>/model/myModel.ecore.
The "Load resource dialog" only offers 2 load options : "browse from
workspace" or "browse from file system". It can be enhanced in reusing
the one from the EMF Ecore editor, that offers a 3rd load option "Browse
from registered packages".
>>
>> 2) Multi-diagram support, navigation between diagrams and sub-diagrams.
> I believe this is there.
>> 2bis) Multi packages support with navigation in their related diagrams.
> I think this is too.
It perfectly works with Topcased.
>>
>> 3) Diagrams serialized in their own files independent from the ecore
>> ones.
> I'm sure this is supported.
Indeed.
>>
>> 4) GMF L&F.
> It's based on GMF, so this must be the case.
I'm not sure to have the popup menu that appears on diagram to create
model elements as in the GMF-based example ? (It's not important)
>>
>> 5) Be able to open diagrams located either in workspace or in target
>> platform (ie use URIEditorInput rather than FileEditorInput)
> Likely this is just a matter of the Diagrams being available in the
> binary plugins. After all, platform:/plugin/<plugin-id>/... will load
> from an installed plugin, so that should work reasonably the same way
> loading Ecore or GenModels work. I'm not sure what mechanism would be
> used to actually open an editor directly for that though. The IDE
> doesn't have an "Open URI" action...
>>
I agree with you.
At the moment, if I'am right, Topcased Ecore editor
only handles FileInputEditor. I'am sure, it's not a big issue to move to
URIEditorInput as you did in the Ecore2Ecore editor.
In JDT or PDE, there are some JarEditorInput (internal API) to be able
to open files included in jared plug-ins (e.g it's used to open
plugin.xml or MANIFEST.MF). But from my point of view, it is simpler to
use an URIEditorInput.
>> 6) Export diagrams in different image formats : GIF, PNG, SVG,...
> I assume this is provided by GMF. Whatever GMF provides should end up
> being surfaced.
>>
>> 7) "Delete from diagram" & "Delete from model" features.
> Yes, I would need this too.
>>
>> 8) Initialize a diagram content from an existing ecore (Improvement of
>> the Topcased initialization algorithm would be appreciated, eUML2 does
>> better that)
> I already tried this and it worked. I've never tried eUML2.
Try with the Library model provided in EMF tutorial, and you will get a
diagram where connections betweens model elements are in all directions.
Not easy to read and to re-arrange.
eUML2 layouts model elements in different layers (top to bottom) that
are driven by inheritance between classes.
From my point of view, it's a good idea, and the diagram is clearer to
read.
>>
>> 9) Have the possibility to hide (or show) some diagram parts :
>> relationships between metaclasses by type (association,
>> aggregation...), attributes...
> You mean a dynamic filter capability as opposed to deleting them from
> the diagram?
Yes, a dynamic filter capability, it allows the end-user to get a
diagram showing only classes and inheritance or classes with association
relationships, or abstract classes or whatever....
It is a usual capability in GIS software like in Google Earth where you
can display or not buildings, roads, restaurants,...
>>
>> I know that most of these needs are already fulfilled by Topcased
>> Ecore editor.
> This editor is already looking very good to me. Did you try installing
> it. The code base was approved to be committed to CVS yesterday and we
> plan to help David with setting up builds. It's so exciting!
Yes, I install it and integrate it in the software I am working on. It's
the "Ecore editor" to design business models.
It would be a pleasure to download the future Ecore Tools builds to test
it and report potential issues.
A last suggestion, when you are designing a big model, it could be
useful to have such features:
"show in diagram" from a selected element in the outline.
"show in outline" from a selected element in the diagram.
It allows the end-user to easily retrieve its model elements. If you are
not the one who designed a model, it helps to navigate in its contained
elements.
>>
>> Hope it helps,
>> Stephane.
>>
--
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #610297 is a reply to message #101261] |
Thu, 08 November 2007 07:29 |
David Sciamma
Messages: 78
Registered: July 2009 |
Member |
|
|
Hi,
Thank you all for your feedback, we will try to implement the best Ecore
Editor we can do.
Comments below.
Stéphane Fournier a écrit :
> Hi, Ed,
> Comments below.
>
> Ed Merks wrote:
>> Stephane,
>>
>> Comments below.
>>
>>
>> Stephane wrote:
>>> Hi,
>>>
>>> I was looking for a graphical Ecore editor. Ed Merks told me to have
>>> a look at the Ecore Tools proposal.
>>>
>>> Here are some needs (requirements) for such an editor:
>>> 1) Be able to add dependencies to models located either in workspace
>>> or in target platform (as the Load resource from the Sample Ecore
>>> editor).
>> This should be trivial to support.
>
> Now, in Topcased, to add a dependency to a model hosted by a plug-in in
> the target platform, you have to enter the path by hand like
> platform:/plugin/<plugin-id>/model/myModel.ecore.
> The "Load resource dialog" only offers 2 load options : "browse from
> workspace" or "browse from file system". It can be enhanced in reusing
> the one from the EMF Ecore editor, that offers a 3rd load option "Browse
> from registered packages".
In Topcased, we added an item in the Outline called "Registered Package"
to be able to import objects. In a first implementation we will reuse
the dialog from EMF Ecore Editor.
>
>>>
>>> 2) Multi-diagram support, navigation between diagrams and sub-diagrams.
>> I believe this is there.
>>> 2bis) Multi packages support with navigation in their related diagrams.
>> I think this is too.
> It perfectly works with Topcased.
Multi-diagram must still be improved in GMF.
>>>
>>> 3) Diagrams serialized in their own files independent from the ecore
>>> ones.
>> I'm sure this is supported.
> Indeed.
>>>
>>> 4) GMF L&F.
>> It's based on GMF, so this must be the case.
> I'm not sure to have the popup menu that appears on diagram to create
> model elements as in the GMF-based example ? (It's not important)
>>>
>>> 5) Be able to open diagrams located either in workspace or in target
>>> platform (ie use URIEditorInput rather than FileEditorInput)
>> Likely this is just a matter of the Diagrams being available in the
>> binary plugins. After all, platform:/plugin/<plugin-id>/... will load
>> from an installed plugin, so that should work reasonably the same way
>> loading Ecore or GenModels work. I'm not sure what mechanism would be
>> used to actually open an editor directly for that though. The IDE
>> doesn't have an "Open URI" action...
We will reuse implementation from GMF and not from Topcased for this
mechanism.
>>>
> I agree with you.
> At the moment, if I'am right, Topcased Ecore editor
> only handles FileInputEditor. I'am sure, it's not a big issue to move to
> URIEditorInput as you did in the Ecore2Ecore editor.
> In JDT or PDE, there are some JarEditorInput (internal API) to be able
> to open files included in jared plug-ins (e.g it's used to open
> plugin.xml or MANIFEST.MF). But from my point of view, it is simpler to
> use an URIEditorInput.
>
>>> 6) Export diagrams in different image formats : GIF, PNG, SVG,...
>> I assume this is provided by GMF. Whatever GMF provides should end up
>> being surfaced.
>>>
>>> 7) "Delete from diagram" & "Delete from model" features.
>> Yes, I would need this too.
It is a major requirement for us too
>>>
>>> 8) Initialize a diagram content from an existing ecore (Improvement
>>> of the Topcased initialization algorithm would be appreciated, eUML2
>>> does better that)
>> I already tried this and it worked. I've never tried eUML2.
> Try with the Library model provided in EMF tutorial, and you will get a
> diagram where connections betweens model elements are in all directions.
> Not easy to read and to re-arrange.
> eUML2 layouts model elements in different layers (top to bottom) that
> are driven by inheritance between classes.
> From my point of view, it's a good idea, and the diagram is clearer to
> read.
Soyatec (eUML2 developers) is interested in the Ecore Tools Component so
perhaps it could be a first external contribution :)
>
>>>
>>> 9) Have the possibility to hide (or show) some diagram parts :
>>> relationships between metaclasses by type (association,
>>> aggregation...), attributes...
>> You mean a dynamic filter capability as opposed to deleting them from
>> the diagram?
> Yes, a dynamic filter capability, it allows the end-user to get a
> diagram showing only classes and inheritance or classes with association
> relationships, or abstract classes or whatever....
> It is a usual capability in GIS software like in Google Earth where you
> can display or not buildings, roads, restaurants,...
We have develop a first solution for another GMF editor and we are
working on its "generalization"
>
>
>>>
>>> I know that most of these needs are already fulfilled by Topcased
>>> Ecore editor.
>> This editor is already looking very good to me. Did you try
>> installing it. The code base was approved to be committed to CVS
>> yesterday and we plan to help David with setting up builds. It's so
>> exciting!
>
> Yes, I install it and integrate it in the software I am working on. It's
> the "Ecore editor" to design business models.
>
> It would be a pleasure to download the future Ecore Tools builds to test
> it and report potential issues.
>
> A last suggestion, when you are designing a big model, it could be
> useful to have such features:
> "show in diagram" from a selected element in the outline.
> "show in outline" from a selected element in the diagram.
> It allows the end-user to easily retrieve its model elements. If you are
> not the one who designed a model, it helps to navigate in its contained
> elements.
>
We plan to implement a "Link with editor"-like mechanism (a toggle
button on the outline) doing this like the package editor do for Java
objects.
>>>
>>> Hope it helps,
>>> Stephane.
>>>
>
Sure it will help,
--
David SCIAMMA
Expert Eclipse / Eclipse Expert
ANYWARE TECHNOLOGIES
Tel : + 33 (0)5.61.00.73.44
Fax : + 33 (0)5.61.00.51.46
http://www.anyware-tech.com
|
|
| |
| Re: [Ecore Tools Proposal] feedback [message #610467 is a reply to message #101980] |
Thu, 08 November 2007 17:56 |
Ed Merks
Messages: 33188
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020408090201000806070301
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Felix,
I don't want to put words in peoples mouths, but I assume that if you do
"Delete from model" the object is deleted from the .ecore and that this
also deletes all references to this object and anything associated with
those references (in coming and outgoing arrows), while "Delete from
Diagram" just says, leave my model alone, I just don't want to see this
thing in this particular diagram because this diagram is a view and I
don't want it to be a view of everything at once...
Felix Dorner wrote:
> Hi,
>
>
>>>>> 7) "Delete from diagram" & "Delete from model" features.
>>>>>
>>>> Yes, I would need this too.
>>>>
>> It is a major requirement for us too
>>
>
> Can you explain this further? I´m sure I am misunderstanding: You´ d
> like to delete an element from the model and keep it in the diagram and
> the inverse? Does this mean you want to sync model and diagram files by
> hand?
>
> What until now was keeping me from the old topcased editor and also the
> one provided by gmf was the fear of a desynced relation between the
> model and the diagram, which indeed happend with the gmf editor. I
> understand that one might want to hide some elements from the diagram
> that exist in the model though.
>
> Felix
>
--------------020408090201000806070301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Felix,<br>
<br>
I don't want to put words in peoples mouths, but I assume that if you
do "Delete from model" the object is deleted from the .ecore and that
this also deletes all references to this object and anything associated
with those references (in coming and outgoing arrows), while "Delete
from Diagram" just says, leave my model alone, I just don't want to see
this thing in this particular diagram because this diagram is a view
and I don't want it to be a view of everything at once...<br>
<br>
<br>
Felix Dorner wrote:
<blockquote cite="mid:fgvf2c$mb9$1@build.eclipse.org" type="cite">
<pre wrap="">Hi,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">7) "Delete from diagram" & "Delete from model" features.
</pre>
</blockquote>
<pre wrap="">Yes, I would need this too.
</pre>
</blockquote>
</blockquote>
<pre wrap="">It is a major requirement for us too
</pre>
</blockquote>
<pre wrap=""><!---->
Can you explain this further? I´m sure I am misunderstanding: You´ d
like to delete an element from the model and keep it in the diagram and
the inverse? Does this mean you want to sync model and diagram files by
hand?
What until now was keeping me from the old topcased editor and also the
one provided by gmf was the fear of a desynced relation between the
model and the diagram, which indeed happend with the gmf editor. I
understand that one might want to hide some elements from the diagram
that exist in the model though.
Felix
</pre>
</blockquote>
<br>
</body>
</html>
--------------020408090201000806070301--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [Ecore Tools Proposal] feedback [message #612421 is a reply to message #101994] |
Fri, 09 November 2007 13:42 |
Ed Willink
Messages: 7665
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> I don't want to put words in peoples mouths, but I assume that if you do
> "Delete from model" the object is deleted from the .ecore and that this
> also deletes all references to this object and anything associated with
> those references (in coming and outgoing arrows), while "Delete from
> Diagram" just says, leave my model alone, I just don't want to see this
> thing in this particular diagram because this diagram is a view and I
> don't want it to be a view of everything at once...
Hi Ed. Exactly my interpretation too. In my second attempt at a UMLX
editor I found that this ergonomic distinction is much more widespread.
A surprising number of edits that can be performed on a diagram/view can
also be differently be performed on the underlying (Ecore) model.
For instance:
Reconnect: ie. drag connection end from one node to another can be:
Reconnect-in-model, which is change EReference.eType and fix-up all diagrams,
or Reconnect-in-diagram, which is delete previous EReference instantiation
and create new EReference instantiation leaving the model unchanged, the
view just shows a different element from the model.
Instantiate: ie. drag an outline/navigator element into the diagram can be:
Create-in-model, which is create a new EClass or whatever, or
Create-in-diagram, which is display an additional element from the model
in the diagram.
With numerous commands having diagram/model alternatives it is helpful
to use a consistent keying: In EDiagram Bugzilla 106208 I suggested
XXX for XXX-in-diagram and CTRL-XXX as XXX-in-model etc.
When I implemented this myself, I found the need to CTRL-XXX to do Ecore
edits was a bit surprising and irritating, however not imposing a consistent
policy makes it difficult to support both forms of edit consistently.
However (Bugzilla 107367), the 'CTRL' key needs careful choice since
the more obvious Shift+DEL is a standard Eclipse equivalent for CUT.
The 'In-Model' 'shift' key must be available to uniformly qualify a variety
of keystokes.
Regards
Ed Willink
|
|
|
Goto Forum:
Current Time: Sat Jul 27 15:03:30 GMT 2024
Powered by FUDForum. Page generated in 0.05287 seconds |
] 
Search
Help
Register
Login
Home
