Home » Modeling » EMF » Split model into two/multiple files
| | | |
| Re: Split model into two/multiple files [message #418444 is a reply to message #418428] |
Wed, 16 April 2008 13:03   |
 Bernd Mühlböck
Messages: 46
Registered: July 2009 |
Member |
|
|
(ecore models below)
There is a already list of metrics (according to Metrics.ecore).
The editor for the Model.ecore should store the Model information and
Node structure in one file, the metrics references of the Nodes in another.
(names are ids)
Model.ecore:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="model"
nsURI="http://www.spqr.org/model" nsPrefix="model">
<eClassifiers xsi:type="ecore:EClass" name="Model">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"
iD="true"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Node">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="children"
eType="#//Node"
eOpposite="#//Node/parent" eKeys="#//Node/name"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="parent"
eType="#//Node"
eOpposite="#//Node/children" eKeys="#//Node/name"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="metrics"
upperBound="-1"
eType="ecore:EClass Metrics.ecore#//Metric"
eKeys="Metrics.ecore#//Metric/name"/>
</eClassifiers>
</ecore:EPackage>
Metrics.ecore:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="metrics"
nsURI="http://www.spqr.org/metrics" nsPrefix="metrics">
<eClassifiers xsi:type="ecore:EClass" name="Metric">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"
iD="true"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="full"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="type"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
</ecore:EPackage>
Thanks,
Bernd
Ed Merks schrieb:
> Bernd,
>
> It would probably help a lot if you had a very concrete scenario. I.e.,
> a specific model for which you were reallying trying to solve these
> problems rather than something completely general and abstract. EMF
> lets you decompose your models literally to the point where each object
> could be in a different resource. Even cross resource containment is
> supported. So at this point, your question is a bit too open ended for
> me to point out specific things you might try.
>
>
> Bernd Mühlböck wrote:
>> Thanks Ed,
>>
>> Although I was hoping to get away without coding...
>>
>> Could you outline where I have to make changes?
>> Would changing the serialization be a (good) alternative?
>>
>>
>> Cheers,
>> Bernd
>>
>>
>>
>> Ed Merks schrieb:
>>> Bernd,
>>>
>>> You can't define the model to automatically partition an instance
>>> into separate resources but you could do something like that
>>> automatically within an editor by specializing the behavior of the
>>> commands that edit the model.
>>>
>>>
>>> Bernd Mühlböck wrote:
>>>> Can you define models where the editor automatically stores elements
>>>> in different files?
>>>>
>>>> For example:
>>>>
>>>> A filesystem-like structure:
>>>> - the directories (and their structure) are stored in one model file.
>>>> - the files (and their association to the directories) are stored in
>>>> another.
>>>>
>>>>
>>>> Thanks,
>>>> Bernd
>>>>
|
|
|
| Re: Split model into two/multiple files [message #418445 is a reply to message #418444] |
Wed, 16 April 2008 13:20 |
Bernd Mühlböck
Messages: 46
Registered: July 2009 |
Member |
|
|
sorry, wrong Model.ecore.
Here is the right one:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="model"
nsURI="http://www.spqr.org/model" nsPrefix="model">
<eClassifiers xsi:type="ecore:EClass" name="Model">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"
iD="true"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="nodes"
upperBound="-1"
eType="#//Node" containment="true" eKeys="#//Node/name"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Node">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="children"
upperBound="-1"
eType="#//Node" eOpposite="#//Node/parent" eKeys="#//Node/name"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="parent"
eType="#//Node"
eOpposite="#//Node/children" eKeys="#//Node/name"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="metrics"
upperBound="-1"
eType="ecore:EClass Metrics.ecore#//Metric"
eKeys="Metrics.ecore#//Metric/name"/>
</eClassifiers>
</ecore:EPackage>
Cheers,
Bernd
Bernd Mühlböck schrieb:
> (ecore models below)
>
> There is a already list of metrics (according to Metrics.ecore).
> The editor for the Model.ecore should store the Model information and
> Node structure in one file, the metrics references of the Nodes in another.
> (names are ids)
>
>
>
> Model.ecore:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="model"
> nsURI="http://www.spqr.org/model" nsPrefix="model">
> <eClassifiers xsi:type="ecore:EClass" name="Model">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"
> iD="true"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Node">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="children"
> eType="#//Node"
> eOpposite="#//Node/parent" eKeys="#//Node/name"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="parent"
> eType="#//Node"
> eOpposite="#//Node/children" eKeys="#//Node/name"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="metrics"
> upperBound="-1"
> eType="ecore:EClass Metrics.ecore#//Metric"
> eKeys="Metrics.ecore#//Metric/name"/>
> </eClassifiers>
> </ecore:EPackage>
>
> Metrics.ecore:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="metrics"
> nsURI="http://www.spqr.org/metrics" nsPrefix="metrics">
> <eClassifiers xsi:type="ecore:EClass" name="Metric">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"
> iD="true"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="full"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="type"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
> </ecore:EPackage>
>
>
>
> Thanks,
> Bernd
>
>
>
>
>
> Ed Merks schrieb:
>> Bernd,
>>
>> It would probably help a lot if you had a very concrete scenario.
>> I.e., a specific model for which you were reallying trying to solve
>> these problems rather than something completely general and abstract.
>> EMF lets you decompose your models literally to the point where each
>> object could be in a different resource. Even cross resource
>> containment is supported. So at this point, your question is a bit
>> too open ended for me to point out specific things you might try.
>>
>>
>> Bernd Mühlböck wrote:
>>> Thanks Ed,
>>>
>>> Although I was hoping to get away without coding...
>>>
>>> Could you outline where I have to make changes?
>>> Would changing the serialization be a (good) alternative?
>>>
>>>
>>> Cheers,
>>> Bernd
>>>
>>>
>>>
>>> Ed Merks schrieb:
>>>> Bernd,
>>>>
>>>> You can't define the model to automatically partition an instance
>>>> into separate resources but you could do something like that
>>>> automatically within an editor by specializing the behavior of the
>>>> commands that edit the model.
>>>>
>>>>
>>>> Bernd Mühlböck wrote:
>>>>> Can you define models where the editor automatically stores
>>>>> elements in different files?
>>>>>
>>>>> For example:
>>>>>
>>>>> A filesystem-like structure:
>>>>> - the directories (and their structure) are stored in one model file.
>>>>> - the files (and their association to the directories) are stored
>>>>> in another.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Bernd
>>>>>
|
|
|
| Re: Split model into two/multiple files [message #418448 is a reply to message #418445] |
Wed, 16 April 2008 13:48 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Bernd,
It refers to a Metrics.ecore, so it's kind of hard to work with when I
don't have that other model...
Bernd Mühlböck wrote:
> sorry, wrong Model.ecore.
>
> Here is the right one:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="model"
> nsURI="http://www.spqr.org/model" nsPrefix="model">
> <eClassifiers xsi:type="ecore:EClass" name="Model">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"
> iD="true"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="nodes"
> upperBound="-1"
> eType="#//Node" containment="true" eKeys="#//Node/name"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Node">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="children"
> upperBound="-1"
> eType="#//Node" eOpposite="#//Node/parent" eKeys="#//Node/name"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="parent"
> eType="#//Node"
> eOpposite="#//Node/children" eKeys="#//Node/name"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="metrics"
> upperBound="-1"
> eType="ecore:EClass Metrics.ecore#//Metric"
> eKeys="Metrics.ecore#//Metric/name"/>
> </eClassifiers>
> </ecore:EPackage>
>
>
> Cheers,
> Bernd
>
>
>
> Bernd Mühlböck schrieb:
>> (ecore models below)
>>
>> There is a already list of metrics (according to Metrics.ecore).
>> The editor for the Model.ecore should store the Model information and
>> Node structure in one file, the metrics references of the Nodes in
>> another.
>> (names are ids)
>>
>>
>>
>> Model.ecore:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="model"
>> nsURI="http://www.spqr.org/model" nsPrefix="model">
>> <eClassifiers xsi:type="ecore:EClass" name="Model">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>> lowerBound="1" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"
>> iD="true"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>> eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="Node">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>> lowerBound="1" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>> eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="children"
>> eType="#//Node"
>> eOpposite="#//Node/parent" eKeys="#//Node/name"/>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="parent"
>> eType="#//Node"
>> eOpposite="#//Node/children" eKeys="#//Node/name"/>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="metrics"
>> upperBound="-1"
>> eType="ecore:EClass Metrics.ecore#//Metric"
>> eKeys="Metrics.ecore#//Metric/name"/>
>> </eClassifiers>
>> </ecore:EPackage>
>>
>> Metrics.ecore:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="metrics"
>> nsURI="http://www.spqr.org/metrics" nsPrefix="metrics">
>> <eClassifiers xsi:type="ecore:EClass" name="Metric">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>> lowerBound="1" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"
>> iD="true"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="full"
>> eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="type"
>> eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>> eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> </eClassifiers>
>> </ecore:EPackage>
>>
>>
>>
>> Thanks,
>> Bernd
>>
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Bernd,
>>>
>>> It would probably help a lot if you had a very concrete scenario.
>>> I.e., a specific model for which you were reallying trying to solve
>>> these problems rather than something completely general and
>>> abstract. EMF lets you decompose your models literally to the point
>>> where each object could be in a different resource. Even cross
>>> resource containment is supported. So at this point, your question
>>> is a bit too open ended for me to point out specific things you
>>> might try.
>>>
>>>
>>> Bernd Mühlböck wrote:
>>>> Thanks Ed,
>>>>
>>>> Although I was hoping to get away without coding...
>>>>
>>>> Could you outline where I have to make changes?
>>>> Would changing the serialization be a (good) alternative?
>>>>
>>>>
>>>> Cheers,
>>>> Bernd
>>>>
>>>>
>>>>
>>>> Ed Merks schrieb:
>>>>> Bernd,
>>>>>
>>>>> You can't define the model to automatically partition an instance
>>>>> into separate resources but you could do something like that
>>>>> automatically within an editor by specializing the behavior of the
>>>>> commands that edit the model.
>>>>>
>>>>>
>>>>> Bernd Mühlböck wrote:
>>>>>> Can you define models where the editor automatically stores
>>>>>> elements in different files?
>>>>>>
>>>>>> For example:
>>>>>>
>>>>>> A filesystem-like structure:
>>>>>> - the directories (and their structure) are stored in one model
>>>>>> file.
>>>>>> - the files (and their association to the directories) are stored
>>>>>> in another.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Bernd
>>>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Split model into two/multiple files [message #418449 is a reply to message #418448] |
Wed, 16 April 2008 13:55 |
Bernd Mühlböck
Messages: 46
Registered: July 2009 |
Member |
|
|
Metrics.ecore is in the post before, or down below here.
Ed Merks schrieb:
> Bernd,
>
> It refers to a Metrics.ecore, so it's kind of hard to work with when I
> don't have that other model...
>
>
> Bernd Mühlböck wrote:
>> sorry, wrong Model.ecore.
>>
>> Here is the right one:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="model"
>> nsURI="http://www.spqr.org/model" nsPrefix="model">
>> <eClassifiers xsi:type="ecore:EClass" name="Model">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>> lowerBound="1" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"
>> iD="true"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="nodes"
>> upperBound="-1"
>> eType="#//Node" containment="true" eKeys="#//Node/name"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="Node">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>> lowerBound="1" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="children"
>> upperBound="-1"
>> eType="#//Node" eOpposite="#//Node/parent" eKeys="#//Node/name"/>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="parent"
>> eType="#//Node"
>> eOpposite="#//Node/children" eKeys="#//Node/name"/>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="metrics"
>> upperBound="-1"
>> eType="ecore:EClass Metrics.ecore#//Metric"
>> eKeys="Metrics.ecore#//Metric/name"/>
>> </eClassifiers>
>> </ecore:EPackage>
>>
>>
>> Cheers,
>> Bernd
>>
>>
>>
>> Bernd Mühlböck schrieb:
>>> (ecore models below)
>>>
>>> There is a already list of metrics (according to Metrics.ecore).
>>> The editor for the Model.ecore should store the Model information and
>>> Node structure in one file, the metrics references of the Nodes in
>>> another.
>>> (names are ids)
>>>
>>>
>>>
>>> Model.ecore:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <ecore:EPackage xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="model"
>>> nsURI="http://www.spqr.org/model" nsPrefix="model">
>>> <eClassifiers xsi:type="ecore:EClass" name="Model">
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>> lowerBound="1" eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"
>>> iD="true"/>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>>> eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>> </eClassifiers>
>>> <eClassifiers xsi:type="ecore:EClass" name="Node">
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>> lowerBound="1" eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>>> eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>> <eStructuralFeatures xsi:type="ecore:EReference" name="children"
>>> eType="#//Node"
>>> eOpposite="#//Node/parent" eKeys="#//Node/name"/>
>>> <eStructuralFeatures xsi:type="ecore:EReference" name="parent"
>>> eType="#//Node"
>>> eOpposite="#//Node/children" eKeys="#//Node/name"/>
>>> <eStructuralFeatures xsi:type="ecore:EReference" name="metrics"
>>> upperBound="-1"
>>> eType="ecore:EClass Metrics.ecore#//Metric"
>>> eKeys="Metrics.ecore#//Metric/name"/>
>>> </eClassifiers>
>>> </ecore:EPackage>
>>>
>>> Metrics.ecore:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <ecore:EPackage xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="metrics"
>>> nsURI="http://www.spqr.org/metrics" nsPrefix="metrics">
>>> <eClassifiers xsi:type="ecore:EClass" name="Metric">
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>> lowerBound="1" eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"
>>> iD="true"/>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="full"
>>> eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="type"
>>> eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>>> eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>> </eClassifiers>
>>> </ecore:EPackage>
>>>
>>>
>>>
>>> Thanks,
>>> Bernd
>>>
>>>
>>>
>>>
>>>
>>> Ed Merks schrieb:
>>>> Bernd,
>>>>
>>>> It would probably help a lot if you had a very concrete scenario.
>>>> I.e., a specific model for which you were reallying trying to solve
>>>> these problems rather than something completely general and
>>>> abstract. EMF lets you decompose your models literally to the point
>>>> where each object could be in a different resource. Even cross
>>>> resource containment is supported. So at this point, your question
>>>> is a bit too open ended for me to point out specific things you
>>>> might try.
>>>>
>>>>
>>>> Bernd Mühlböck wrote:
>>>>> Thanks Ed,
>>>>>
>>>>> Although I was hoping to get away without coding...
>>>>>
>>>>> Could you outline where I have to make changes?
>>>>> Would changing the serialization be a (good) alternative?
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Bernd
>>>>>
>>>>>
>>>>>
>>>>> Ed Merks schrieb:
>>>>>> Bernd,
>>>>>>
>>>>>> You can't define the model to automatically partition an instance
>>>>>> into separate resources but you could do something like that
>>>>>> automatically within an editor by specializing the behavior of the
>>>>>> commands that edit the model.
>>>>>>
>>>>>>
>>>>>> Bernd Mühlböck wrote:
>>>>>>> Can you define models where the editor automatically stores
>>>>>>> elements in different files?
>>>>>>>
>>>>>>> For example:
>>>>>>>
>>>>>>> A filesystem-like structure:
>>>>>>> - the directories (and their structure) are stored in one model
>>>>>>> file.
>>>>>>> - the files (and their association to the directories) are stored
>>>>>>> in another.
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bernd
>>>>>>>
|
|
|
| Re: Split model into two/multiple files [message #418451 is a reply to message #418449] |
Wed, 16 April 2008 14:23 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Bernd,
Sorry, I didn't scroll far enough. So I gather the Model will contain
all the nodes and then the nodes will cross reference each other via
non-containment references; but maybe you meant to make "children" a
containment references so that the Model only contains the root Nodes.
The nodes that refer to various Metric instance which I assume are
likely the things you want in a separate file. It's certainly possible
to generate the Metric model separately and then to be able to create
resources that contain a Metric instance. When you open a resource to
edit the "Model" model, you'll be able to use Load Resource... from the
popup menu to load one more more Metric-containing resource and once
you've loaded them, their instances will be available in the properties
view for populating the metrics reference of a node. Is that the kind
of thing you had in mind? Maybe you don't need anything automatic given
the user will be able to control completely how things are partitioned.
Bernd Mühlböck wrote:
> Metrics.ecore is in the post before, or down below here.
>
>
>
> Ed Merks schrieb:
>> Bernd,
>>
>> It refers to a Metrics.ecore, so it's kind of hard to work with when
>> I don't have that other model...
>>
>>
>> Bernd Mühlböck wrote:
>>> sorry, wrong Model.ecore.
>>>
>>> Here is the right one:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <ecore:EPackage xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="model"
>>> nsURI="http://www.spqr.org/model" nsPrefix="model">
>>> <eClassifiers xsi:type="ecore:EClass" name="Model">
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>> lowerBound="1" eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"
>>> iD="true"/>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>>> eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>> <eStructuralFeatures xsi:type="ecore:EReference" name="nodes"
>>> upperBound="-1"
>>> eType="#//Node" containment="true" eKeys="#//Node/name"/>
>>> </eClassifiers>
>>> <eClassifiers xsi:type="ecore:EClass" name="Node">
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>> lowerBound="1" eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>>> eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>> <eStructuralFeatures xsi:type="ecore:EReference" name="children"
>>> upperBound="-1"
>>> eType="#//Node" eOpposite="#//Node/parent"
>>> eKeys="#//Node/name"/>
>>> <eStructuralFeatures xsi:type="ecore:EReference" name="parent"
>>> eType="#//Node"
>>> eOpposite="#//Node/children" eKeys="#//Node/name"/>
>>> <eStructuralFeatures xsi:type="ecore:EReference" name="metrics"
>>> upperBound="-1"
>>> eType="ecore:EClass Metrics.ecore#//Metric"
>>> eKeys="Metrics.ecore#//Metric/name"/>
>>> </eClassifiers>
>>> </ecore:EPackage>
>>>
>>>
>>> Cheers,
>>> Bernd
>>>
>>>
>>>
>>> Bernd Mühlböck schrieb:
>>>> (ecore models below)
>>>>
>>>> There is a already list of metrics (according to Metrics.ecore).
>>>> The editor for the Model.ecore should store the Model information
>>>> and Node structure in one file, the metrics references of the Nodes
>>>> in another.
>>>> (names are ids)
>>>>
>>>>
>>>>
>>>> Model.ecore:
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <ecore:EPackage xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="model"
>>>> nsURI="http://www.spqr.org/model" nsPrefix="model">
>>>> <eClassifiers xsi:type="ecore:EClass" name="Model">
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>>> lowerBound="1" eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"
>>>> iD="true"/>
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>>>> eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>> </eClassifiers>
>>>> <eClassifiers xsi:type="ecore:EClass" name="Node">
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>>> lowerBound="1" eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>>>> eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>> <eStructuralFeatures xsi:type="ecore:EReference"
>>>> name="children" eType="#//Node"
>>>> eOpposite="#//Node/parent" eKeys="#//Node/name"/>
>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="parent"
>>>> eType="#//Node"
>>>> eOpposite="#//Node/children" eKeys="#//Node/name"/>
>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="metrics"
>>>> upperBound="-1"
>>>> eType="ecore:EClass Metrics.ecore#//Metric"
>>>> eKeys="Metrics.ecore#//Metric/name"/>
>>>> </eClassifiers>
>>>> </ecore:EPackage>
>>>>
>>>> Metrics.ecore:
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <ecore:EPackage xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="metrics"
>>>> nsURI="http://www.spqr.org/metrics" nsPrefix="metrics">
>>>> <eClassifiers xsi:type="ecore:EClass" name="Metric">
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>>> lowerBound="1" eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"
>>>> iD="true"/>
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="full"
>>>> eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="type"
>>>> eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
>>>> eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>> </eClassifiers>
>>>> </ecore:EPackage>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Bernd
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Ed Merks schrieb:
>>>>> Bernd,
>>>>>
>>>>> It would probably help a lot if you had a very concrete scenario.
>>>>> I.e., a specific model for which you were reallying trying to
>>>>> solve these problems rather than something completely general and
>>>>> abstract. EMF lets you decompose your models literally to the
>>>>> point where each object could be in a different resource. Even
>>>>> cross resource containment is supported. So at this point, your
>>>>> question is a bit too open ended for me to point out specific
>>>>> things you might try.
>>>>>
>>>>>
>>>>> Bernd Mühlböck wrote:
>>>>>> Thanks Ed,
>>>>>>
>>>>>> Although I was hoping to get away without coding...
>>>>>>
>>>>>> Could you outline where I have to make changes?
>>>>>> Would changing the serialization be a (good) alternative?
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Bernd
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ed Merks schrieb:
>>>>>>> Bernd,
>>>>>>>
>>>>>>> You can't define the model to automatically partition an
>>>>>>> instance into separate resources but you could do something like
>>>>>>> that automatically within an editor by specializing the behavior
>>>>>>> of the commands that edit the model.
>>>>>>>
>>>>>>>
>>>>>>> Bernd Mühlböck wrote:
>>>>>>>> Can you define models where the editor automatically stores
>>>>>>>> elements in different files?
>>>>>>>>
>>>>>>>> For example:
>>>>>>>>
>>>>>>>> A filesystem-like structure:
>>>>>>>> - the directories (and their structure) are stored in one model
>>>>>>>> file.
>>>>>>>> - the files (and their association to the directories) are
>>>>>>>> stored in another.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Bernd
>>>>>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Split model into two/multiple files [message #418463 is a reply to message #418460] |
Wed, 16 April 2008 18:49 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Bernd,
All the item providers inherit from ItemProviderAdapter, and that class
has methods like createSetCommand/createAddCommand and so on. These (or
methods like factorAddCommand) can all be specialized to do additional
or alternative things. So you might for example allow an C to be
added to an A but automatically create a B that will hold C and add B to
A instead. You might even create a resource to hold B. You'd like use
a compound command to compose all these results from smaller fine
grained commands.
Bernd Mühlböck wrote:
> I will consider the containment for the Nodes.
>
> The Load Resource... "trick" works great (with drag & drop, ...).
> I altered the Metric.ecore to contain a list (see new ecores below).
> Instead of referencing the Metrics directly, I now have a relationship
> model Node2Model.
>
> So there now are 3 files (as required):
>
> ..metrics: list of Metrics
> ..model: Model, Nodes
> ..n2m: list of relations Node->Metric
>
>
> How can I tweak the editor, so that it automatically creates a
> Relation (containment in .n2m) and references it, when I drag & drop a
> Metric on a Node. The crux is the containment in the other file.
>
>
> 3 models follow:
> ================
> Metrics.ecore:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="metrics"
> nsURI="http://www.spqr.org/metrics" nsPrefix="metrics">
> <eClassifiers xsi:type="ecore:EClass" name="Root">
> <eStructuralFeatures xsi:type="ecore:EReference" name="metrics"
> upperBound="-1"
> eType="#//Metric" containment="true" eKeys="#//Metric/name"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Metric">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"
> iD="true"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="full"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="type"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
> </ecore:EPackage>
>
> Model.ecore:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="model"
> nsURI="http://www.spqr.org/model" nsPrefix="model">
> <eClassifiers xsi:type="ecore:EClass" name="Model">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"
> iD="true"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="nodes"
> upperBound="-1"
> eType="#//Node" containment="true" eKeys="#//Node/name"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Node">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"
> iD="true"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="desc"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="children"
> upperBound="-1"
> eType="#//Node" containment="true" eOpposite="#//Node/parent"
> eKeys="#//Node/name"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="parent"
> eType="#//Node"
> eOpposite="#//Node/children" eKeys="#//Node/name"/>
> <eStructuralFeatures xsi:type="ecore:EReference"
> name="metricRelation" upperBound="-1"
> eType="ecore:EClass Node2Metric.ecore#//Relation"
> eOpposite="Node2Metric.ecore#//Relation/node"/>
> </eClassifiers>
> </ecore:EPackage>
>
> Node2Metric.ecore
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="n2m"
> nsURI="http://www.spqr.org/n2m" nsPrefix="n2m">
> <eClassifiers xsi:type="ecore:EClass" name="Root">
> <eStructuralFeatures xsi:type="ecore:EReference" name="relations"
> upperBound="-1"
> eType="#//Relation" containment="true"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Relation">
> <eStructuralFeatures xsi:type="ecore:EReference" name="node"
> lowerBound="1" eType="ecore:EClass Model.ecore#//Node"
> eOpposite="Model.ecore#//Node/metricRelation"
> eKeys="Model.ecore#//Node/name"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="metric"
> lowerBound="1"
> eType="ecore:EClass Metrics.ecore#//Metric"
> eKeys="Metrics.ecore#//Metric/name"/>
> </eClassifiers>
> </ecore:EPackage>
>
>
> Thanks,
> Bernd
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 19:34:33 GMT 2024
Powered by FUDForum. Page generated in 0.07583 seconds |
] 
Search
Help
Register
Login
Home
