Home » Modeling » EMF » Use Commands from "foreign" model
| | |
| Re: Use Commands from "foreign" model [message #420764 is a reply to message #420763] |
Wed, 09 July 2008 23:51   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Bernd,
I'm usually pretty good at reading between the lines, but I really have
no idea what you are hoping to accomplish. If you want specific
advice, please try to come up with something concrete that I can sink my
teeth into.
Bernd Mühlböck wrote:
> The resources are implicitly related through their filenames (same
> path/name, different extension: A: *.model, B: *.relation). Sorry, I
> should have mentioned that;-)
>
> For example, getChildren() of my NodeItemProvider (A) looks for the
> "related" *.relation file in order to add the leaves. However there is
> no real cross reference.
>
>
>
> Ed Merks wrote
>> Bernd,
>>
>> Comments below.
>>
>> Bernd Mühlböck wrote:
>>> In my editor there are nodes that don't come directly from the model
>>> (A), but from an unrelated model (B).
>> Unrelated...
>>> The only connection is that the nodes of B have stored the ids of
>>> related nodes of A (there should be no other cross reference).
>> So B "Nodes" have EAttributes that store IDs of nodes in A; but what
>> about the information to indicate which resource contains an object
>> with that ID?
>>>
>>> How do I implement the commands in A so that I can add/remove/dnd
>>> the nodes that come from B?
>> I thought you said A had no relation to B...
>>>
>>> B should not be added to the EditingDomain of A.
>> A and B aren't really added to an editing domain...
>>> Can I create a new EditingDomain for the handling of B?
>> I'm completely in the dark. How about showing a more specific
>> example with actual classes that have specific attributes and
>> references...
>>>
>>> Thanks,
>>> Bernd
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Use Commands from "foreign" model [message #420765 is a reply to message #420764] |
Thu, 10 July 2008 00:42 |
Bernd Mühlböck
Messages: 46
Registered: July 2009 |
Member |
|
|
So, from the start...
The emf editor should work like a basic file explorer (eg. Windows
Explorer).
The "folders" (nodes) are stored in a file (*.model):
Model
-> 0..* nodes : Node
Node
-> 1 name : String (id = true)
-> 0..* children : Node
There is a predefined list of "files" (metrics) that doesn't change
(*.metrics):
Root
-> 0..* metrics : Metric
Metric
-> 1 name : String (id = true)
-> ... <other information>
The connection between the nodes and the metrics is stored in a third
file (*.relation). It has a direct reference to the Metric, but only the
id of the node is stored:
Root
-> 0..* relations : Relation
Relation
-> 1 nodeID : String
-> 1 metric : Metric
The implementation of *.model (eg. NodeItemProvider.getChildren) can
access the *.relation resource because it knows that it has the same
filename, but ends with ".relation".
Done:
- Show the Metrics as children of the Nodes.
Questions:
1) How can I add "Add Child - Metric" behavior to a Node (in the editor)?
2) How do I implement the Add/Remove/DND Commands in the
NodeItemProvider, so that it manipulates the *.relation resource?
Thanks for reading (and answers),
Bernd
Ed Merks wrote:
> Bernd,
>
> I'm usually pretty good at reading between the lines, but I really have
> no idea what you are hoping to accomplish. If you want specific
> advice, please try to come up with something concrete that I can sink my
> teeth into.
>
>
> Bernd Mühlböck wrote:
>> The resources are implicitly related through their filenames (same
>> path/name, different extension: A: *.model, B: *.relation). Sorry, I
>> should have mentioned that;-)
>>
>> For example, getChildren() of my NodeItemProvider (A) looks for the
>> "related" *.relation file in order to add the leaves. However there is
>> no real cross reference.
>>
>>
>>
>> Ed Merks wrote
>>> Bernd,
>>>
>>> Comments below.
>>>
>>> Bernd Mühlböck wrote:
>>>> In my editor there are nodes that don't come directly from the model
>>>> (A), but from an unrelated model (B).
>>> Unrelated...
>>>> The only connection is that the nodes of B have stored the ids of
>>>> related nodes of A (there should be no other cross reference).
>>> So B "Nodes" have EAttributes that store IDs of nodes in A; but what
>>> about the information to indicate which resource contains an object
>>> with that ID?
>>>>
>>>> How do I implement the commands in A so that I can add/remove/dnd
>>>> the nodes that come from B?
>>> I thought you said A had no relation to B...
>>>>
>>>> B should not be added to the EditingDomain of A.
>>> A and B aren't really added to an editing domain...
>>>> Can I create a new EditingDomain for the handling of B?
>>> I'm completely in the dark. How about showing a more specific
>>> example with actual classes that have specific attributes and
>>> references...
>>>>
>>>> Thanks,
>>>> Bernd
|
|
|
| Re: Use Commands from "foreign" model [message #420769 is a reply to message #420765] |
Thu, 10 July 2008 10:28 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Bernd,
Comments below.
Bernd Mühlböck wrote:
> So, from the start...
> The emf editor should work like a basic file explorer (eg. Windows
> Explorer).
>
> The "folders" (nodes) are stored in a file (*.model):
>
> Model
> -> 0..* nodes : Node
> Node
> -> 1 name : String (id = true)
> -> 0..* children : Node
So a containment tree of Nodes where each node has an ID that's unique
within the tree.
>
> There is a predefined list of "files" (metrics) that doesn't change
> (*.metrics):
>
> Root
> -> 0..* metrics : Metric
> Metric
> -> 1 name : String (id = true)
> -> ... <other information>
So a two level tree with Metrics as leaves where each Metric has an ID
that's unique within the tree.
>
> The connection between the nodes and the metrics is stored in a third
> file (*.relation). It has a direct reference to the Metric, but only
> the id of the node is stored:
>
> Root
> -> 0..* relations : Relation
> Relation
> -> 1 nodeID : String
So this is like an IDREF but the referenced object is actually in
another resource, though the resource can be derived from
relation.eResource().trimFileExtension().appendFileExtension ( "model").
> -> 1 metric : Metric
>
>
> The implementation of *.model (eg. NodeItemProvider.getChildren) can
> access the *.relation resource because it knows that it has the same
> filename, but ends with ".relation".
So like
node.eResource().trimFileExtension().appendFileExtension("relation ").
>
> Done:
> - Show the Metrics as children of the Nodes.
So it has to find each relation whose nodeID matches the node's name.
>
> Questions:
>
> 1) How can I add "Add Child - Metric" behavior to a Node (in the editor)?
You could specialize the NodeItemProvider.collectNewChildDescriptors
method to create a descriptor for the Metric. There's no real feature
to specify, so I suppose it will be null or just a string; not sure.
Then you'll want to specialize createCreateChildCommand to handle this
descriptor in an appropriate way, i.e., a compound command that will add
the Metric where it really belongs. It might be the case that you'd
onloy need to specialize the createAddCommand...
> 2) How do I implement the Add/Remove/DND Commands in the
> NodeItemProvider, so that it manipulates the *.relation resource?
You'd need to specialize
NodeItemProvider.createAddCommand/createRemoveCommand and so on to act
upon the Metrics.
>
>
>
> Thanks for reading (and answers),
It all makes more sense with the details laid out... Life might be a
lot simpler if Node had a derived transient reference to point at the
Metrics. Then your editor would be using that relationship to show the
metric children...
> Bernd
>
>
>
> Ed Merks wrote:
>> Bernd,
>>
>> I'm usually pretty good at reading between the lines, but I really
>> have no idea what you are hoping to accomplish. If you want
>> specific advice, please try to come up with something concrete that I
>> can sink my teeth into.
>>
>>
>> Bernd Mühlböck wrote:
>>> The resources are implicitly related through their filenames (same
>>> path/name, different extension: A: *.model, B: *.relation). Sorry, I
>>> should have mentioned that;-)
>>>
>>> For example, getChildren() of my NodeItemProvider (A) looks for the
>>> "related" *.relation file in order to add the leaves. However there
>>> is no real cross reference.
>>>
>>>
>>>
>>> Ed Merks wrote
>>>> Bernd,
>>>>
>>>> Comments below.
>>>>
>>>> Bernd Mühlböck wrote:
>>>>> In my editor there are nodes that don't come directly from the
>>>>> model (A), but from an unrelated model (B).
>>>> Unrelated...
>>>>> The only connection is that the nodes of B have stored the ids of
>>>>> related nodes of A (there should be no other cross reference).
>>>> So B "Nodes" have EAttributes that store IDs of nodes in A; but
>>>> what about the information to indicate which resource contains an
>>>> object with that ID?
>>>>>
>>>>> How do I implement the commands in A so that I can add/remove/dnd
>>>>> the nodes that come from B?
>>>> I thought you said A had no relation to B...
>>>>>
>>>>> B should not be added to the EditingDomain of A.
>>>> A and B aren't really added to an editing domain...
>>>>> Can I create a new EditingDomain for the handling of B?
>>>> I'm completely in the dark. How about showing a more specific
>>>> example with actual classes that have specific attributes and
>>>> references...
>>>>>
>>>>> Thanks,
>>>>> Bernd
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Use Commands from "foreign" model [message #420822 is a reply to message #420769] |
Fri, 11 July 2008 10:49 |
Bernd Mühlböck
Messages: 46
Registered: July 2009 |
Member |
|
|
Thanks for the comments.
I now had the idea to put the whole thing (all three models) into one
big model and just let the ResourceImpl do the division into the files.
This should simplify the customization of the editor.
Are there any negative points to it that I'm missing?
Cheers,
Bernd
Ed Merks schrieb:
> Bernd,
>
> Comments below.
>
> Bernd Mühlböck wrote:
>> So, from the start...
>> The emf editor should work like a basic file explorer (eg. Windows
>> Explorer).
>>
>> The "folders" (nodes) are stored in a file (*.model):
>>
>> Model
>> -> 0..* nodes : Node
>> Node
>> -> 1 name : String (id = true)
>> -> 0..* children : Node
> So a containment tree of Nodes where each node has an ID that's unique
> within the tree.
>>
>> There is a predefined list of "files" (metrics) that doesn't change
>> (*.metrics):
>>
>> Root
>> -> 0..* metrics : Metric
>> Metric
>> -> 1 name : String (id = true)
>> -> ... <other information>
> So a two level tree with Metrics as leaves where each Metric has an ID
> that's unique within the tree.
>>
>> The connection between the nodes and the metrics is stored in a third
>> file (*.relation). It has a direct reference to the Metric, but only
>> the id of the node is stored:
>>
>> Root
>> -> 0..* relations : Relation
>> Relation
>> -> 1 nodeID : String
> So this is like an IDREF but the referenced object is actually in
> another resource, though the resource can be derived from
> relation.eResource().trimFileExtension().appendFileExtension ( "model").
>> -> 1 metric : Metric
>>
>>
>> The implementation of *.model (eg. NodeItemProvider.getChildren) can
>> access the *.relation resource because it knows that it has the same
>> filename, but ends with ".relation".
> So like
> node.eResource().trimFileExtension().appendFileExtension("relation ").
>>
>> Done:
>> - Show the Metrics as children of the Nodes.
> So it has to find each relation whose nodeID matches the node's name.
>>
>> Questions:
>>
>> 1) How can I add "Add Child - Metric" behavior to a Node (in the editor)?
> You could specialize the NodeItemProvider.collectNewChildDescriptors
> method to create a descriptor for the Metric. There's no real feature
> to specify, so I suppose it will be null or just a string; not sure.
> Then you'll want to specialize createCreateChildCommand to handle this
> descriptor in an appropriate way, i.e., a compound command that will add
> the Metric where it really belongs. It might be the case that you'd
> onloy need to specialize the createAddCommand...
>> 2) How do I implement the Add/Remove/DND Commands in the
>> NodeItemProvider, so that it manipulates the *.relation resource?
> You'd need to specialize
> NodeItemProvider.createAddCommand/createRemoveCommand and so on to act
> upon the Metrics.
>>
>>
>>
>> Thanks for reading (and answers),
> It all makes more sense with the details laid out... Life might be a
> lot simpler if Node had a derived transient reference to point at the
> Metrics. Then your editor would be using that relationship to show the
> metric children...
>> Bernd
>>
>>
>>
>> Ed Merks wrote:
>>> Bernd,
>>>
>>> I'm usually pretty good at reading between the lines, but I really
>>> have no idea what you are hoping to accomplish. If you want
>>> specific advice, please try to come up with something concrete that I
>>> can sink my teeth into.
>>>
>>>
>>> Bernd Mühlböck wrote:
>>>> The resources are implicitly related through their filenames (same
>>>> path/name, different extension: A: *.model, B: *.relation). Sorry, I
>>>> should have mentioned that;-)
>>>>
>>>> For example, getChildren() of my NodeItemProvider (A) looks for the
>>>> "related" *.relation file in order to add the leaves. However there
>>>> is no real cross reference.
>>>>
>>>>
>>>>
>>>> Ed Merks wrote
>>>>> Bernd,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Bernd Mühlböck wrote:
>>>>>> In my editor there are nodes that don't come directly from the
>>>>>> model (A), but from an unrelated model (B).
>>>>> Unrelated...
>>>>>> The only connection is that the nodes of B have stored the ids of
>>>>>> related nodes of A (there should be no other cross reference).
>>>>> So B "Nodes" have EAttributes that store IDs of nodes in A; but
>>>>> what about the information to indicate which resource contains an
>>>>> object with that ID?
>>>>>>
>>>>>> How do I implement the commands in A so that I can add/remove/dnd
>>>>>> the nodes that come from B?
>>>>> I thought you said A had no relation to B...
>>>>>>
>>>>>> B should not be added to the EditingDomain of A.
>>>>> A and B aren't really added to an editing domain...
>>>>>> Can I create a new EditingDomain for the handling of B?
>>>>> I'm completely in the dark. How about showing a more specific
>>>>> example with actual classes that have specific attributes and
>>>>> references...
>>>>>>
>>>>>> Thanks,
>>>>>> Bernd
|
|
|
| Re: Use Commands from "foreign" model [message #420823 is a reply to message #420822] |
Fri, 11 July 2008 11:02 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Bernd,
EMF Resources are typically in one-to-one correspondence with actual
files. Consider a method like save where you pass in the input stream;
it's expected to work like "save as"...
Bernd Mühlböck wrote:
> Thanks for the comments.
>
> I now had the idea to put the whole thing (all three models) into one
> big model and just let the ResourceImpl do the division into the
> files. This should simplify the customization of the editor.
>
> Are there any negative points to it that I'm missing?
>
> Cheers,
> Bernd
>
>
> Ed Merks schrieb:
>> Bernd,
>>
>> Comments below.
>>
>> Bernd Mühlböck wrote:
>>> So, from the start...
>>> The emf editor should work like a basic file explorer (eg. Windows
>>> Explorer).
>>>
>>> The "folders" (nodes) are stored in a file (*.model):
>>>
>>> Model
>>> -> 0..* nodes : Node
>>> Node
>>> -> 1 name : String (id = true)
>>> -> 0..* children : Node
>> So a containment tree of Nodes where each node has an ID that's
>> unique within the tree.
>>>
>>> There is a predefined list of "files" (metrics) that doesn't change
>>> (*.metrics):
>>>
>>> Root
>>> -> 0..* metrics : Metric
>>> Metric
>>> -> 1 name : String (id = true)
>>> -> ... <other information>
>> So a two level tree with Metrics as leaves where each Metric has an
>> ID that's unique within the tree.
>>>
>>> The connection between the nodes and the metrics is stored in a
>>> third file (*.relation). It has a direct reference to the Metric,
>>> but only the id of the node is stored:
>>>
>>> Root
>>> -> 0..* relations : Relation
>>> Relation
>>> -> 1 nodeID : String
>> So this is like an IDREF but the referenced object is actually in
>> another resource, though the resource can be derived from
>> relation.eResource().trimFileExtension().appendFileExtension ( "model").
>>> -> 1 metric : Metric
>>>
>>>
>>> The implementation of *.model (eg. NodeItemProvider.getChildren) can
>>> access the *.relation resource because it knows that it has the same
>>> filename, but ends with ".relation".
>> So like
>> node.eResource().trimFileExtension().appendFileExtension("relation ").
>>>
>>> Done:
>>> - Show the Metrics as children of the Nodes.
>> So it has to find each relation whose nodeID matches the node's name.
>>>
>>> Questions:
>>>
>>> 1) How can I add "Add Child - Metric" behavior to a Node (in the
>>> editor)?
>> You could specialize the NodeItemProvider.collectNewChildDescriptors
>> method to create a descriptor for the Metric. There's no real
>> feature to specify, so I suppose it will be null or just a string;
>> not sure. Then you'll want to specialize createCreateChildCommand to
>> handle this descriptor in an appropriate way, i.e., a compound
>> command that will add the Metric where it really belongs. It might be
>> the case that you'd onloy need to specialize the createAddCommand...
>>> 2) How do I implement the Add/Remove/DND Commands in the
>>> NodeItemProvider, so that it manipulates the *.relation resource?
>> You'd need to specialize
>> NodeItemProvider.createAddCommand/createRemoveCommand and so on to
>> act upon the Metrics.
>>>
>>>
>>>
>>> Thanks for reading (and answers),
>> It all makes more sense with the details laid out... Life might be a
>> lot simpler if Node had a derived transient reference to point at the
>> Metrics. Then your editor would be using that relationship to show
>> the metric children...
>>> Bernd
>>>
>>>
>>>
>>> Ed Merks wrote:
>>>> Bernd,
>>>>
>>>> I'm usually pretty good at reading between the lines, but I really
>>>> have no idea what you are hoping to accomplish. If you want
>>>> specific advice, please try to come up with something concrete that
>>>> I can sink my teeth into.
>>>>
>>>>
>>>> Bernd Mühlböck wrote:
>>>>> The resources are implicitly related through their filenames (same
>>>>> path/name, different extension: A: *.model, B: *.relation). Sorry,
>>>>> I should have mentioned that;-)
>>>>>
>>>>> For example, getChildren() of my NodeItemProvider (A) looks for
>>>>> the "related" *.relation file in order to add the leaves. However
>>>>> there is no real cross reference.
>>>>>
>>>>>
>>>>>
>>>>> Ed Merks wrote
>>>>>> Bernd,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Bernd Mühlböck wrote:
>>>>>>> In my editor there are nodes that don't come directly from the
>>>>>>> model (A), but from an unrelated model (B).
>>>>>> Unrelated...
>>>>>>> The only connection is that the nodes of B have stored the ids
>>>>>>> of related nodes of A (there should be no other cross reference).
>>>>>> So B "Nodes" have EAttributes that store IDs of nodes in A; but
>>>>>> what about the information to indicate which resource contains an
>>>>>> object with that ID?
>>>>>>>
>>>>>>> How do I implement the commands in A so that I can
>>>>>>> add/remove/dnd the nodes that come from B?
>>>>>> I thought you said A had no relation to B...
>>>>>>>
>>>>>>> B should not be added to the EditingDomain of A.
>>>>>> A and B aren't really added to an editing domain...
>>>>>>> Can I create a new EditingDomain for the handling of B?
>>>>>> I'm completely in the dark. How about showing a more specific
>>>>>> example with actual classes that have specific attributes and
>>>>>> references...
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bernd
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 08:14:35 GMT 2024
Powered by FUDForum. Page generated in 0.03324 seconds |
] 
Search
Help
Register
Login
Home
