Creating objects with multi-valued children [message #483396] |
Tue, 01 September 2009 13:09  |
Eclipse User |
|
|
|
If I were to create a simple object that has a containment association
with an N..N value (as shown in the "simple" model below), is there a
proper place in which I can modify the generated code such that the
contained objects are always of the correct number?
In this example, could I modify one of the factories such that a "Car"
object is always created with 4 "Tire" child objects?
TIA
<?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="simple"
nsURI="http://nunjobiznezz.com/emf/simple" nsPrefix="simple">
<eClassifiers xsi:type="ecore:EClass" name="Car">
<eStructuralFeatures xsi:type="ecore:EReference" name="tires"
lowerBound="4" upperBound="4"
eType="#//Tires" containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Tires"/>
</ecore:EPackage>
|
|
|
Re: Creating objects with multi-valued children [message #485079 is a reply to message #483396] |
Thu, 10 September 2009 13:43   |
Eclipse User |
|
|
|
Doug,
Yes, modifying the factory to do additional initialization for newly
created objects would make sense. An alternative would be to attach a
listener which detects creation/addition of a new car and responds by
creating/adding the necessary tires.
Kenn
Doug Bercot wrote:
> If I were to create a simple object that has a containment association
> with an N..N value (as shown in the "simple" model below), is there a
> proper place in which I can modify the generated code such that the
> contained objects are always of the correct number?
>
> In this example, could I modify one of the factories such that a "Car"
> object is always created with 4 "Tire" child objects?
>
> TIA
>
> <?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="simple"
> nsURI="http://nunjobiznezz.com/emf/simple" nsPrefix="simple">
> <eClassifiers xsi:type="ecore:EClass" name="Car">
> <eStructuralFeatures xsi:type="ecore:EReference" name="tires"
> lowerBound="4" upperBound="4"
> eType="#//Tires" containment="true"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Tires"/>
> </ecore:EPackage>
>
>
|
|
|
Re: Creating objects with multi-valued children [message #485080 is a reply to message #485079] |
Thu, 10 September 2009 13:48  |
Eclipse User |
|
|
|
I should clarify that, as Ed pointed out in another thread, the
additional initialization should be done in a new/separate factory
method. Likewise, the listener approach could present problems during
serialization or copying, depending on whether notifications are enabled
and/or when the listener processes the notifications it receives.
The approach that's taken in UML2 is to create factory methods on the
classes themselves, rather than in the factory. This is one way to
distinguish between the default methods provided, and required, by the
EMF framework, and convenience methods that are need by clients of your
API...
Kenn
Kenn Hussey wrote:
> Doug,
>
> Yes, modifying the factory to do additional initialization for newly
> created objects would make sense. An alternative would be to attach a
> listener which detects creation/addition of a new car and responds by
> creating/adding the necessary tires.
>
> Kenn
>
> Doug Bercot wrote:
>> If I were to create a simple object that has a containment association
>> with an N..N value (as shown in the "simple" model below), is there a
>> proper place in which I can modify the generated code such that the
>> contained objects are always of the correct number?
>>
>> In this example, could I modify one of the factories such that a "Car"
>> object is always created with 4 "Tire" child objects?
>>
>> TIA
>>
>> <?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="simple"
>> nsURI="http://nunjobiznezz.com/emf/simple" nsPrefix="simple">
>> <eClassifiers xsi:type="ecore:EClass" name="Car">
>> <eStructuralFeatures xsi:type="ecore:EReference" name="tires"
>> lowerBound="4" upperBound="4"
>> eType="#//Tires" containment="true"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="Tires"/>
>> </ecore:EPackage>
>>
>>
|
|
|
Re: Creating objects with multi-valued children [message #597759 is a reply to message #483396] |
Thu, 10 September 2009 13:43  |
Eclipse User |
|
|
|
Doug,
Yes, modifying the factory to do additional initialization for newly
created objects would make sense. An alternative would be to attach a
listener which detects creation/addition of a new car and responds by
creating/adding the necessary tires.
Kenn
Doug Bercot wrote:
> If I were to create a simple object that has a containment association
> with an N..N value (as shown in the "simple" model below), is there a
> proper place in which I can modify the generated code such that the
> contained objects are always of the correct number?
>
> In this example, could I modify one of the factories such that a "Car"
> object is always created with 4 "Tire" child objects?
>
> TIA
>
> <?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="simple"
> nsURI="http://nunjobiznezz.com/emf/simple" nsPrefix="simple">
> <eClassifiers xsi:type="ecore:EClass" name="Car">
> <eStructuralFeatures xsi:type="ecore:EReference" name="tires"
> lowerBound="4" upperBound="4"
> eType="#//Tires" containment="true"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Tires"/>
> </ecore:EPackage>
>
>
|
|
|
Re: Creating objects with multi-valued children [message #597763 is a reply to message #485079] |
Thu, 10 September 2009 13:48  |
Eclipse User |
|
|
|
I should clarify that, as Ed pointed out in another thread, the
additional initialization should be done in a new/separate factory
method. Likewise, the listener approach could present problems during
serialization or copying, depending on whether notifications are enabled
and/or when the listener processes the notifications it receives.
The approach that's taken in UML2 is to create factory methods on the
classes themselves, rather than in the factory. This is one way to
distinguish between the default methods provided, and required, by the
EMF framework, and convenience methods that are need by clients of your
API...
Kenn
Kenn Hussey wrote:
> Doug,
>
> Yes, modifying the factory to do additional initialization for newly
> created objects would make sense. An alternative would be to attach a
> listener which detects creation/addition of a new car and responds by
> creating/adding the necessary tires.
>
> Kenn
>
> Doug Bercot wrote:
>> If I were to create a simple object that has a containment association
>> with an N..N value (as shown in the "simple" model below), is there a
>> proper place in which I can modify the generated code such that the
>> contained objects are always of the correct number?
>>
>> In this example, could I modify one of the factories such that a "Car"
>> object is always created with 4 "Tire" child objects?
>>
>> TIA
>>
>> <?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="simple"
>> nsURI="http://nunjobiznezz.com/emf/simple" nsPrefix="simple">
>> <eClassifiers xsi:type="ecore:EClass" name="Car">
>> <eStructuralFeatures xsi:type="ecore:EReference" name="tires"
>> lowerBound="4" upperBound="4"
>> eType="#//Tires" containment="true"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="Tires"/>
>> </ecore:EPackage>
>>
>>
|
|
|
Powered by
FUDForum. Page generated in 0.05629 seconds