Home » Modeling » EMF » implementing factory override
| implementing factory override [message #487583] |
Wed, 23 September 2009 16:16  |
|
Hi
I was trying to provide a customized factory (following the epo3 example
of the book, for instance, for adding automatically an Item to a
PurchaseOrder when creating a PurchaseOrder);
I then implemented this simple derived class from the generated one:
public class EFactory1 extends EPO3FactoryImpl {
public PurchaseOrder createPurchaseOrder() {
PurchaseOrder purchaseOrder = super.createPurchaseOrder();
Item item = createItem();
item.setComment("default item");
purchaseOrder.getItems().add(item);
return purchaseOrder;
}
}
and used the extension point:
<extension
point="org.eclipse.emf.ecore.factory_override">
<factory
class="com.example.epo3.impl.EFactory1"
uri="com.example.epo3.factory1">
</factory>
</extension>
however, my factory is not actually used, for instance, in the generated
tree based editor when adding new PurchaseOrders... are there any other
required steps to use the custom factory?
thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: implementing factory override [message #487587 is a reply to message #487583] |
Wed, 23 September 2009 16:31  |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Hi,
I don't know about your particular problem, but in general it is not a
good idea to change the standard class creation methods and putting in
default data.
The reason for this is because if you serialize out to an XMI file, and
then try to read it back in again you will get some duplicate stuff created.
For instance using what you've shown here and then serializing it out.
The serialized file will contain a PurchaseOrder with an Item inside it.
Now when you read the XMI back in, you will have TWO Items, the one that
got created through the factory when the parser calls
createPurchaseOrder() and then the one that was in your XMI file. They
both will say "default item".
Lorenzo Bettini wrote:
> Hi
>
> I was trying to provide a customized factory (following the epo3 example
> of the book, for instance, for adding automatically an Item to a
> PurchaseOrder when creating a PurchaseOrder);
>
> I then implemented this simple derived class from the generated one:
>
> public class EFactory1 extends EPO3FactoryImpl {
> public PurchaseOrder createPurchaseOrder() {
> PurchaseOrder purchaseOrder = super.createPurchaseOrder();
>
> Item item = createItem();
> item.setComment("default item");
> purchaseOrder.getItems().add(item);
>
> return purchaseOrder;
> }
> }
--
Thanks,
Rich Kulp
|
|
|
| Re: implementing factory override [message #487595 is a reply to message #487587] |
Wed, 23 September 2009 16:45 |
 Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Comments below.
Rich Kulp wrote:
> Hi,
>
> I don't know about your particular problem, but in general it is not a
> good idea to change the standard class creation methods and putting in
> default data.
>
> The reason for this is because if you serialize out to an XMI file,
> and then try to read it back in again you will get some duplicate
> stuff created.
>
> For instance using what you've shown here and then serializing it out.
> The serialized file will contain a PurchaseOrder with an Item inside
> it. Now when you read the XMI back in, you will have TWO Items, the
> one that got created through the factory when the parser calls
> createPurchaseOrder() and then the one that was in your XMI file. They
> both will say "default item".
Exactly, it's a bad idea.
>
> Lorenzo Bettini wrote:
>> Hi
>>
>> I was trying to provide a customized factory (following the epo3
>> example of the book, for instance, for adding automatically an Item
>> to a PurchaseOrder when creating a PurchaseOrder);
>>
>> I then implemented this simple derived class from the generated one:
>>
>> public class EFactory1 extends EPO3FactoryImpl {
>> public PurchaseOrder createPurchaseOrder() {
>> PurchaseOrder purchaseOrder = super.createPurchaseOrder();
>> Item item = createItem();
>> item.setComment("default item");
>> purchaseOrder.getItems().add(item);
>> return purchaseOrder;
>> }
No, don't do this. This type of thing only makes sense in the generated
editor, not at the basic model level which, as Rich suggests, expects be
handed blank new instances. You should look into specializing the
collectNewChildDescriptors code to create initialized instances in the
editor.
>> }
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: implementing factory override [message #487596 is a reply to message #487595] |
Wed, 23 September 2009 16:50 |
|
Thanks Ed and Rich for your quick answers.
Sorry for providing a bad example, but I just wanted to try a customized
factory, which however is not used, and I wanted to know why it is not
used in spite of using the plugin.xml extension. :-)
Could you please tell me why it is no used?
cheers
Lorenzo
Ed Merks wrote:
> Comments below.
>
> Rich Kulp wrote:
>> Hi,
>>
>> I don't know about your particular problem, but in general it is not a
>> good idea to change the standard class creation methods and putting in
>> default data.
>>
>> The reason for this is because if you serialize out to an XMI file,
>> and then try to read it back in again you will get some duplicate
>> stuff created.
>>
>> For instance using what you've shown here and then serializing it out.
>> The serialized file will contain a PurchaseOrder with an Item inside
>> it. Now when you read the XMI back in, you will have TWO Items, the
>> one that got created through the factory when the parser calls
>> createPurchaseOrder() and then the one that was in your XMI file. They
>> both will say "default item".
> Exactly, it's a bad idea.
>>
>> Lorenzo Bettini wrote:
>>> Hi
>>>
>>> I was trying to provide a customized factory (following the epo3
>>> example of the book, for instance, for adding automatically an Item
>>> to a PurchaseOrder when creating a PurchaseOrder);
>>>
>>> I then implemented this simple derived class from the generated one:
>>>
>>> public class EFactory1 extends EPO3FactoryImpl {
>>> public PurchaseOrder createPurchaseOrder() {
>>> PurchaseOrder purchaseOrder = super.createPurchaseOrder();
>>> Item item = createItem();
>>> item.setComment("default item");
>>> purchaseOrder.getItems().add(item);
>>> return purchaseOrder;
>>> }
> No, don't do this. This type of thing only makes sense in the generated
> editor, not at the basic model level which, as Rich suggests, expects be
> handed blank new instances. You should look into specializing the
> collectNewChildDescriptors code to create initialized instances in the
> editor.
>>> }
>>
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: implementing factory override [message #487605 is a reply to message #487596] |
Wed, 23 September 2009 17:09 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Lorenzo,
Is uri="com.example.epo3.factory1" also the nsURI of the package whose
factory you're trying to modify?
Lorenzo Bettini wrote:
> Thanks Ed and Rich for your quick answers.
>
> Sorry for providing a bad example, but I just wanted to try a
> customized factory, which however is not used, and I wanted to know
> why it is not used in spite of using the plugin.xml extension. :-)
>
> Could you please tell me why it is no used?
>
> cheers
> Lorenzo
>
> Ed Merks wrote:
>> Comments below.
>>
>> Rich Kulp wrote:
>>> Hi,
>>>
>>> I don't know about your particular problem, but in general it is not
>>> a good idea to change the standard class creation methods and
>>> putting in default data.
>>>
>>> The reason for this is because if you serialize out to an XMI file,
>>> and then try to read it back in again you will get some duplicate
>>> stuff created.
>>>
>>> For instance using what you've shown here and then serializing it
>>> out. The serialized file will contain a PurchaseOrder with an Item
>>> inside it. Now when you read the XMI back in, you will have TWO
>>> Items, the one that got created through the factory when the parser
>>> calls createPurchaseOrder() and then the one that was in your XMI
>>> file. They both will say "default item".
>> Exactly, it's a bad idea.
>>>
>>> Lorenzo Bettini wrote:
>>>> Hi
>>>>
>>>> I was trying to provide a customized factory (following the epo3
>>>> example of the book, for instance, for adding automatically an Item
>>>> to a PurchaseOrder when creating a PurchaseOrder);
>>>>
>>>> I then implemented this simple derived class from the generated one:
>>>>
>>>> public class EFactory1 extends EPO3FactoryImpl {
>>>> public PurchaseOrder createPurchaseOrder() {
>>>> PurchaseOrder purchaseOrder = super.createPurchaseOrder();
>>>> Item item = createItem();
>>>> item.setComment("default item");
>>>> purchaseOrder.getItems().add(item);
>>>> return purchaseOrder;
>>>> }
>> No, don't do this. This type of thing only makes sense in the
>> generated editor, not at the basic model level which, as Rich
>> suggests, expects be handed blank new instances. You should look
>> into specializing the collectNewChildDescriptors code to create
>> initialized instances in the editor.
>>>> }
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: implementing factory override [message #487725 is a reply to message #487605] |
Thu, 24 September 2009 08:59 |
|
ooops... No! I've modified that into http://www.example.com/epo3.ecore
and now it works!
Sorry about the noise, but I thought that would represent simply the id
of the factory, or that the uri would have defaulted to the one of the
model package
thanks
Lorenzo
Ed Merks wrote:
> Lorenzo,
>
> Is uri="com.example.epo3.factory1" also the nsURI of the package whose
> factory you're trying to modify?
>
>
> Lorenzo Bettini wrote:
>> Thanks Ed and Rich for your quick answers.
>>
>> Sorry for providing a bad example, but I just wanted to try a
>> customized factory, which however is not used, and I wanted to know
>> why it is not used in spite of using the plugin.xml extension. :-)
>>
>> Could you please tell me why it is no used?
>>
>> cheers
>> Lorenzo
>>
>> Ed Merks wrote:
>>> Comments below.
>>>
>>> Rich Kulp wrote:
>>>> Hi,
>>>>
>>>> I don't know about your particular problem, but in general it is not
>>>> a good idea to change the standard class creation methods and
>>>> putting in default data.
>>>>
>>>> The reason for this is because if you serialize out to an XMI file,
>>>> and then try to read it back in again you will get some duplicate
>>>> stuff created.
>>>>
>>>> For instance using what you've shown here and then serializing it
>>>> out. The serialized file will contain a PurchaseOrder with an Item
>>>> inside it. Now when you read the XMI back in, you will have TWO
>>>> Items, the one that got created through the factory when the parser
>>>> calls createPurchaseOrder() and then the one that was in your XMI
>>>> file. They both will say "default item".
>>> Exactly, it's a bad idea.
>>>>
>>>> Lorenzo Bettini wrote:
>>>>> Hi
>>>>>
>>>>> I was trying to provide a customized factory (following the epo3
>>>>> example of the book, for instance, for adding automatically an Item
>>>>> to a PurchaseOrder when creating a PurchaseOrder);
>>>>>
>>>>> I then implemented this simple derived class from the generated one:
>>>>>
>>>>> public class EFactory1 extends EPO3FactoryImpl {
>>>>> public PurchaseOrder createPurchaseOrder() {
>>>>> PurchaseOrder purchaseOrder = super.createPurchaseOrder();
>>>>> Item item = createItem();
>>>>> item.setComment("default item");
>>>>> purchaseOrder.getItems().add(item);
>>>>> return purchaseOrder;
>>>>> }
>>> No, don't do this. This type of thing only makes sense in the
>>> generated editor, not at the basic model level which, as Rich
>>> suggests, expects be handed blank new instances. You should look
>>> into specializing the collectNewChildDescriptors code to create
>>> initialized instances in the editor.
>>>>> }
>>>>
>>
>>
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| |
| Re: implementing factory override [message #488036 is a reply to message #487980] |
Fri, 25 September 2009 12:23 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Mattias,
Here's something related from EGenericTypeItemProvider
/**
* This adds {@link org.eclipse.emf.edit.command.CommandParameter}s
describing the children
* that can be created under this object.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated NOT
*/
@Override
protected void collectNewChildDescriptors(Collection<Object>
newChildDescriptors, Object object)
{
super.collectNewChildDescriptors(newChildDescriptors, object);
EGenericType eGenericType = (EGenericType)object;
if (eGenericType.eContainmentFeature() ==
EcorePackage.Literals.EGENERIC_TYPE__ETYPE_ARGUMENTS &&
eGenericType.getEClassifier() == null &&
eGenericType.getETypeParameter() == null)
{
newChildDescriptors.add
(createChildParameter
(EcorePackage.Literals.EGENERIC_TYPE__EUPPER_BOUND,
EcoreFactory.eINSTANCE.createEGenericType()));
newChildDescriptors.add
(createChildParameter
(EcorePackage.Literals.EGENERIC_TYPE__ELOWER_BOUND,
EcoreFactory.eINSTANCE.createEGenericType()));
}
if (eGenericType.getEClassifier() != null &&
!eGenericType.getEClassifier().getETypeParameters().isEmpty( ))
{
newChildDescriptors.add
(createChildParameter
(EcorePackage.Literals.EGENERIC_TYPE__ETYPE_ARGUMENTS,
EcoreFactory.eINSTANCE.createEGenericType()));
}
}
You'll see in the generated code that the factory methods are called to
create instances, so it's a simple matter of creating the instance and
initializing it before creating a descriptor around it. There's no need
to use commands to initialize the new object because initialization of
the new object doesn't need to be undoable.
Matthias Schoettle wrote:
> Hi Ed,
>
>> No, don't do this. This type of thing only makes sense in the
>> generated editor, not at the basic model level which, as Rich
>> suggests, expects be handed blank new instances. You should look
>> into specializing the collectNewChildDescriptors code to create
>> initialized instances in the editor.
>
> Is there an example anywhere on how to specialize
> collectNewChildDescriptors to create initialized instances?
>
> - Matthias
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: implementing factory override [message #488542 is a reply to message #488036] |
Tue, 29 September 2009 08:16 |
Matthias Schoettle
Messages: 44
Registered: July 2009 |
Member |
|
|
Hi Ed,
thanks. But the children don't get added automatically to the new
instance, right? How can they be added directly to the instance?
Matthias
Ed Merks wrote:
> Mattias,
>
> Here's something related from EGenericTypeItemProvider
>
> /**
> * This adds {@link org.eclipse.emf.edit.command.CommandParameter}s
> describing the children
> * that can be created under this object.
> * <!-- begin-user-doc -->
> * <!-- end-user-doc -->
> * @generated NOT
> */
> @Override
> protected void collectNewChildDescriptors(Collection<Object>
> newChildDescriptors, Object object)
> {
> super.collectNewChildDescriptors(newChildDescriptors, object);
>
> EGenericType eGenericType = (EGenericType)object;
>
> if (eGenericType.eContainmentFeature() ==
> EcorePackage.Literals.EGENERIC_TYPE__ETYPE_ARGUMENTS &&
> eGenericType.getEClassifier() == null &&
> eGenericType.getETypeParameter() == null)
> {
> newChildDescriptors.add
> (createChildParameter
> (EcorePackage.Literals.EGENERIC_TYPE__EUPPER_BOUND,
> EcoreFactory.eINSTANCE.createEGenericType()));
> newChildDescriptors.add
> (createChildParameter
> (EcorePackage.Literals.EGENERIC_TYPE__ELOWER_BOUND,
> EcoreFactory.eINSTANCE.createEGenericType()));
> }
>
> if (eGenericType.getEClassifier() != null &&
> !eGenericType.getEClassifier().getETypeParameters().isEmpty( ))
> {
> newChildDescriptors.add
> (createChildParameter
> (EcorePackage.Literals.EGENERIC_TYPE__ETYPE_ARGUMENTS,
> EcoreFactory.eINSTANCE.createEGenericType()));
> }
> }
>
> You'll see in the generated code that the factory methods are called to
> create instances, so it's a simple matter of creating the instance and
> initializing it before creating a descriptor around it. There's no need
> to use commands to initialize the new object because initialization of
> the new object doesn't need to be undoable.
>
>
> Matthias Schoettle wrote:
>> Hi Ed,
>>
>>> No, don't do this. This type of thing only makes sense in the
>>> generated editor, not at the basic model level which, as Rich
>>> suggests, expects be handed blank new instances. You should look
>>> into specializing the collectNewChildDescriptors code to create
>>> initialized instances in the editor.
>>
>> Is there an example anywhere on how to specialize
>> collectNewChildDescriptors to create initialized instances?
>>
>> - Matthias
|
|
|
| Re: implementing factory override [message #488559 is a reply to message #488542] |
Tue, 29 September 2009 09:10 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Mattias,
Just create the new instance, create any child instances too, and set
them using the regular accessors to initialize it. In other words, the
object you pass to the descriptor will be initialized and populated with
children of its own.
Matthias Schoettle wrote:
> Hi Ed,
>
> thanks. But the children don't get added automatically to the new
> instance, right? How can they be added directly to the instance?
>
> Matthias
>
> Ed Merks wrote:
>> Mattias,
>>
>> Here's something related from EGenericTypeItemProvider
>>
>> /**
>> * This adds {@link org.eclipse.emf.edit.command.CommandParameter}s
>> describing the children
>> * that can be created under this object.
>> * <!-- begin-user-doc -->
>> * <!-- end-user-doc -->
>> * @generated NOT
>> */
>> @Override
>> protected void collectNewChildDescriptors(Collection<Object>
>> newChildDescriptors, Object object)
>> {
>> super.collectNewChildDescriptors(newChildDescriptors, object);
>>
>> EGenericType eGenericType = (EGenericType)object;
>>
>> if (eGenericType.eContainmentFeature() ==
>> EcorePackage.Literals.EGENERIC_TYPE__ETYPE_ARGUMENTS &&
>> eGenericType.getEClassifier() == null &&
>> eGenericType.getETypeParameter() == null)
>> {
>> newChildDescriptors.add
>> (createChildParameter
>> (EcorePackage.Literals.EGENERIC_TYPE__EUPPER_BOUND,
>> EcoreFactory.eINSTANCE.createEGenericType()));
>> newChildDescriptors.add
>> (createChildParameter
>> (EcorePackage.Literals.EGENERIC_TYPE__ELOWER_BOUND,
>> EcoreFactory.eINSTANCE.createEGenericType()));
>> }
>>
>> if (eGenericType.getEClassifier() != null &&
>> !eGenericType.getEClassifier().getETypeParameters().isEmpty( ))
>> {
>> newChildDescriptors.add
>> (createChildParameter
>> (EcorePackage.Literals.EGENERIC_TYPE__ETYPE_ARGUMENTS,
>> EcoreFactory.eINSTANCE.createEGenericType()));
>> }
>> }
>>
>> You'll see in the generated code that the factory methods are called
>> to create instances, so it's a simple matter of creating the instance
>> and initializing it before creating a descriptor around it. There's
>> no need to use commands to initialize the new object because
>> initialization of the new object doesn't need to be undoable.
>>
>>
>> Matthias Schoettle wrote:
>>> Hi Ed,
>>>
>>>> No, don't do this. This type of thing only makes sense in the
>>>> generated editor, not at the basic model level which, as Rich
>>>> suggests, expects be handed blank new instances. You should look
>>>> into specializing the collectNewChildDescriptors code to create
>>>> initialized instances in the editor.
>>>
>>> Is there an example anywhere on how to specialize
>>> collectNewChildDescriptors to create initialized instances?
>>>
>>> - Matthias
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Sep 20 04:51:13 GMT 2024
Powered by FUDForum. Page generated in 0.04625 seconds |
] 
Search
Help
Register
Login
Home
