Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Creating Children You Didn't Know Existed revisited
Creating Children You Didn't Know Existed revisited [message #636953] Wed, 03 November 2010 14:12 Go to next message
Simon Barner is currently offline Simon BarnerFriend
Messages: 8
Registered: August 2010
Junior Member
Dear all,

I just followed the instructions at
< http://ed-merks.blogspot.com/2008/01/creating-children-you-d idnt-know.html>
to generate editors that can be extended with concrete derived classes.

However, I came across one problem with the "Child Creation Extenders"
/ "Extensible Provider Factory" that will explain using the following
example:

Package test.base:
==================
Base class: test.base.Base
Container class: test.base.ContainerInBase (0..* containment of Base)
Extensible Provider Factory: true

Package test.derived
====================
Derived class test.derived.Derived (inherits from test.base.Base)
Child Creation Extenders: true

If I generate an editor for test.base, I can add both Base and Derived
objects to test.base.ContainerInBase (as expected).

Package test.container
======================
Container class 2: test.container.Container (0..* containment of Base)

The editor for test.container allows me to add Base objects only;
Derived objects cannot be added no matter if I turn on "Child Creation
Extenders" or "Extensible Provider Factory" in the corresponding GenModels.

My questions are: Is this behavior expected?

If yes, how can I work around this problem? Modifying
test.container.provider.ContainerItemProvider.collectNewChil dDescriptors
as follows

protected void collectNewChildDescriptors(Collection<Object>
newChildDescriptors, Object object) {
super.collectNewChildDescriptors(newChildDescriptors, object);

newChildDescriptors.add
(createChildParameter
(ContainerPackage.Literals.CONTAINER__REF,
BaseFactory.eINSTANCE.createBase()));

newChildDescriptors.add
(createChildParameter
(ContainerPackage.Literals.CONTAINER__REF,
DerivedFactory.eINSTANCE.createDerived()));
}

works for classes Base and Derived, but will not work for unknown
subclasses of Base (say Derived2).

For your reference, I exported the above test case and uploaded it here
<http://www6.in.tum.de/~barner/children_test.zip>

I debugged a bit into the code, but I do not have the necessary in-depth
knowledge about how the generated edit and editor code is supposed to
work together.

Thanks in advance,

Regards,
Simon
Re: Creating Children You Didn't Know Existed revisited [message #636962 is a reply to message #636953] Wed, 03 November 2010 14:35 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33137
Registered: July 2009
Senior Member
Simon,

Comments below.

Simon Barner wrote:
> Dear all,
>
> I just followed the instructions at
> < http://ed-merks.blogspot.com/2008/01/creating-children-you-d idnt-know.html>
> to generate editors that can be extended with concrete derived classes.
>
> However, I came across one problem with the "Child Creation Extenders"
> / "Extensible Provider Factory" that will explain using the following
> example:
>
> Package test.base:
> ==================
> Base class: test.base.Base
> Container class: test.base.ContainerInBase (0..* containment of Base)
> Extensible Provider Factory: true
>
> Package test.derived
> ====================
> Derived class test.derived.Derived (inherits from test.base.Base)
> Child Creation Extenders: true
>
> If I generate an editor for test.base, I can add both Base and Derived
> objects to test.base.ContainerInBase (as expected).
>
> Package test.container
> ======================
> Container class 2: test.container.Container (0..* containment of Base)
So this model doesn't know about test.derived and test.derived doesn't
know about this model, so it won't know to contribute anything to this
model.
>
> The editor for test.container allows me to add Base objects only;
> Derived objects cannot be added no matter if I turn on "Child Creation
> Extenders" or "Extensible Provider Factory" in the corresponding
> GenModels.
>
> My questions are: Is this behavior expected?
Yes.
>
> If yes, how can I work around this problem? Modifying
> test.container.provider.ContainerItemProvider.collectNewChil dDescriptors
> as follows
>
> protected void collectNewChildDescriptors(Collection<Object>
> newChildDescriptors, Object object) {
> super.collectNewChildDescriptors(newChildDescriptors, object);
>
> newChildDescriptors.add
> (createChildParameter
> (ContainerPackage.Literals.CONTAINER__REF,
> BaseFactory.eINSTANCE.createBase()));
>
> newChildDescriptors.add
> (createChildParameter
> (ContainerPackage.Literals.CONTAINER__REF,
> DerivedFactory.eINSTANCE.createDerived()));
> }
>
> works for classes Base and Derived, but will not work for unknown
> subclasses of Base (say Derived2).
You'd need to manually (directly in the *.genmodel) add test.container's
GenPackage as a usedGenPackage for test.derived's GenModel.
>
> For your reference, I exported the above test case and uploaded it here
> <http://www6.in.tum.de/~barner/children_test.zip>
>
> I debugged a bit into the code, but I do not have the necessary
> in-depth knowledge about how the generated edit and editor code is
> supposed to work together.
>
> Thanks in advance,
>
> Regards,
> Simon


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Creating Children You Didn't Know Existed revisited [message #637000 is a reply to message #636962] Wed, 03 November 2010 17:25 Go to previous messageGo to next message
Simon Barner is currently offline Simon BarnerFriend
Messages: 8
Registered: August 2010
Junior Member
Ed,

thanks for the swift reply.

>> Package test.container
>> ======================
>> Container class 2: test.container.Container (0..* containment of Base)
> So this model doesn't know about test.derived and test.derived doesn't
> know about this model, so it won't know to contribute anything to this
> model.

Yes, that's what I figured.

> You'd need to manually (directly in the *.genmodel) add test.container's
> GenPackage as a usedGenPackage for test.derived's GenModel.

Great, that worked perfectly. I did the following:

I opened derived.genmodel in the text editor (is there a more elegant
way of doing this?) and adapted the usedGenPackages attribute as follows:

usedGenPackages="base.genmodel#//base container.genmodel#//container"

I also had to enable "Extensible Provider Factory" for the Container
package in container.genmodel.

For me, this solution is quite acceptable, since the set of container
classes is known in advance, and thus this approach scales well when
more derived classes are added.

Thanks again,
Simon
Tree structures and cycles in genmodel (was: Re: Creating Children You Didn't Know Existed revisited [message #637996 is a reply to message #636962] Tue, 09 November 2010 15:08 Go to previous messageGo to next message
Simon Barner is currently offline Simon BarnerFriend
Messages: 8
Registered: August 2010
Junior Member
Dear Ed, dear EMF-tools group,

>> works for classes Base and Derived, but will not work for unknown
>> subclasses of Base (say Derived2).
> You'd need to manually (directly in the *.genmodel) add test.container's
> GenPackage as a usedGenPackage for test.derived's GenModel.

Here a follow-up problem that resulted from further experiments with my
meta-model:

Suppose, I have the following classes:

------------------------------------------------------

Package test.base:
==================
Base class: Base
children (containment 0..* of Base)

Extensible Provider Factory: true


Package test.derived
====================
Derived class Derived (inherits from Base)

Child Creation Extenders: true


Package test.subderived
====================
Derived class Subderived (inherits from Derived)

Child Creation Extenders: true

See <http://www6.in.tum.de/~barner/children_cycle.zip>
------------------------------------------------------

Now, the generated editor code (root element: Base) for test.base
behaves as follows:

Type: Base
Child types offered by editor: Base, Derived, Subderived

Type: Derived
Child types offered by editor: Base, Derived

Type: Subderived
Child types offered by editor: Base, Derived, Subderived

This is of course expected since Derived does not know about Subderived.
However, manually extending 'usedGenPackage' for Derived will not work
since this would lead to a cycle (effect: code generation for
derived.genmodel fails, i.e. no code is generated at all). It seems,
that cycle is not detected because I see a stack overflow exception when
I generate code using emf.Ecore2Java ant task.

Do you have suggestion how to overcome this problem. My current thoughts
are:

1) Make the lookup of child creating extenders walk up the class
hierarchy to the root class (in our case: from Derived to Base)

2) Now, process the entire tree created by the Extensible Provider
Factory/Child Creation Extender mechanism and collect all possible
children (e.g. for Base, Derived and Subderived).

This approach would have the additional benefit that no manual
modification of the .genmodel is needed.

I would appreciate your comments on this suggestion and possibly
implementation hints. Alternative (simpler ;-) ) ideas are certainly
welcome as well.

Thanks in advance,
Simon
Re: Tree structures and cycles in genmodel [message #638267 is a reply to message #637996] Wed, 10 November 2010 14:41 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33137
Registered: July 2009
Senior Member
Simon,

I'm totally swamped after two weeks in Europe. It's best you open a
bugzilla with your test case so I can analyze it in detail. I can't
promise to get to it quickly. Building the packages from a single
GenModel will of course solve the problem for the time being...


Simon Barner wrote:
> Dear Ed, dear EMF-tools group,
>
>>> works for classes Base and Derived, but will not work for unknown
>>> subclasses of Base (say Derived2).
>> You'd need to manually (directly in the *.genmodel) add test.container's
>> GenPackage as a usedGenPackage for test.derived's GenModel.
>
> Here a follow-up problem that resulted from further experiments with
> my meta-model:
>
> Suppose, I have the following classes:
>
> ------------------------------------------------------
>
> Package test.base:
> ==================
> Base class: Base
> children (containment 0..* of Base)
>
> Extensible Provider Factory: true
>
>
> Package test.derived
> ====================
> Derived class Derived (inherits from Base)
>
> Child Creation Extenders: true
>
>
> Package test.subderived
> ====================
> Derived class Subderived (inherits from Derived)
>
> Child Creation Extenders: true
>
> See <http://www6.in.tum.de/~barner/children_cycle.zip>
> ------------------------------------------------------
>
> Now, the generated editor code (root element: Base) for test.base
> behaves as follows:
>
> Type: Base
> Child types offered by editor: Base, Derived, Subderived
>
> Type: Derived
> Child types offered by editor: Base, Derived
>
> Type: Subderived
> Child types offered by editor: Base, Derived, Subderived
>
> This is of course expected since Derived does not know about
> Subderived. However, manually extending 'usedGenPackage' for Derived
> will not work since this would lead to a cycle (effect: code
> generation for derived.genmodel fails, i.e. no code is generated at
> all). It seems, that cycle is not detected because I see a stack
> overflow exception when I generate code using emf.Ecore2Java ant task.
>
> Do you have suggestion how to overcome this problem. My current
> thoughts are:
>
> 1) Make the lookup of child creating extenders walk up the class
> hierarchy to the root class (in our case: from Derived to Base)
>
> 2) Now, process the entire tree created by the Extensible Provider
> Factory/Child Creation Extender mechanism and collect all possible
> children (e.g. for Base, Derived and Subderived).
>
> This approach would have the additional benefit that no manual
> modification of the .genmodel is needed.
>
> I would appreciate your comments on this suggestion and possibly
> implementation hints. Alternative (simpler ;-) ) ideas are certainly
> welcome as well.
>
> Thanks in advance,
> Simon


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:Serialization problem concerning Maps
Next Topic:Access EMF generated classes from JEE remote client
Goto Forum:
  


Current Time: Sat Apr 20 02:39:31 GMT 2024

Powered by FUDForum. Page generated in 0.03124 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top