Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EMF generated POJO containing dynamically overridden EClass
EMF generated POJO containing dynamically overridden EClass [message #421001] Mon, 21 July 2008 10:07 Go to next message
samuel is currently offline samuelFriend
Messages: 11
Registered: July 2009
Junior Member
Hi !

I need some advice about the EMF POJO.

I have a basic model (defined in an ecore) and I need POJO to facilitate the use of this basic model.
Clients need to override the classes of this basic model classes to add their own data.
We don’t want java code modification, only modification of the ecore model (and some OCL rules). So we need to automatically detect overriding in the model in order to dynamically instantiate the overridden classes.

My question is about the POJOs. Should I use the EMF generated code (with the genmodel), or should I implement my own POJO containing the extended EObject,with getter&setter accessing base attributes from the EObject?

I know how to introspect the ecore to get the clients overridden EClass.
But if I use the EMF generated code, I am not sure how to modify the code to instantiate the extended classes in the basic POJO. I thought I just had to change the factory, but it looks more complex…

It looks simpler for me to build my own POJO containing the EObject. But I will loose the benefits of EMF POJO generation and maybe others features?

Thanks in advance for your help!

Regards
Samuel
Re: EMF generated POJO containing dynamically overridden EClass [message #421014 is a reply to message #421001] Mon, 21 July 2008 18:31 Go to previous messageGo to next message
David Steinberg is currently offline David SteinbergFriend
Messages: 489
Registered: July 2009
Senior Member
Hi Samuel,

I'm not sure I fully understand your question, but it seems you're
asking about two things:

1. Creating POJOs that wrap EMF generated classes. This is certainly
possible, but I suspect you'll quickly find that you need to be able to
find the wrapper for a given EObject. For example, if you want find an
object's container, or forward a notification, or get an object loaded
from a serialization, you'll probably want to use the EMF mechanism and
then get the corresponding wrapper for the resulting EObject.

If you can model an attribute in your generated class to hold the
wrapper, that would be easiest. Or, if you don't want to be invasive of
the model that way, another option is to store the wrapper as an adapter
on the EObject. We did this in our SDO implementation, where SDO
metadata classes (Type, Property) wrap corresponding Ecore elements
(EClassifier, EStructuralFeature). For example, look at ETypeImpl and
SDOUtil.getType() to see how the wrapper stores its target directly and
the wrapper is stored on the target as an adapter.

In our case, the wrappers are also EObjects, but the same approach could
be used for your problem of putting non-EObject wrappers over EObjects.

2. Instantiating custom subclasses of generated classes. This seems
like the easier approach, since you won't have to write delegating
implementations of basically everything that EMF already provides. It
should be pretty simple to do, as you suggested: all instances of
generated classes are created by the generated factory, so you just need
to change the createXYZ() methods to create whatever you want.

I don't think this is particularly recommended, though. While I can't
think of anything in particular that would break, it wouldn't shock me
if at some point you find things do. It's not something that we've
really tested.

Does anyone else have experience with this? Is it feasible?

Cheers,
Dave


Samuel wrote:
> Hi !
>
> I need some advice about the EMF POJO.
>
> I have a basic model (defined in an ecore) and I need POJO to facilitate the use of this basic model.
> Clients need to override the classes of this basic model classes to add their own data.
> We don’t want java code modification, only modification of the ecore model (and some OCL rules). So we need to automatically detect overriding in the model in order to dynamically instantiate the overridden classes.
>
> My question is about the POJOs. Should I use the EMF generated code (with the genmodel), or should I implement my own POJO containing the extended EObject,with getter&setter accessing base attributes from the EObject?
>
> I know how to introspect the ecore to get the clients overridden EClass.
> But if I use the EMF generated code, I am not sure how to modify the code to instantiate the extended classes in the basic POJO. I thought I just had to change the factory, but it looks more complex…
>
> It looks simpler for me to build my own POJO containing the EObject. But I will loose the benefits of EMF POJO generation and maybe others features?
>
> Thanks in advance for your help!
>
> Regards
> Samuel
Re: EMF generated POJO containing dynamically overridden EClass [message #421033 is a reply to message #421014] Tue, 22 July 2008 14:24 Go to previous messageGo to next message
samuel is currently offline samuelFriend
Messages: 11
Registered: July 2009
Junior Member
Thanks for your response Dave !

We need to test the two solutions in a prototype, to see what is the best.

To be continued...
Re: EMF generated POJO containing dynamically overridden EClass [message #421356 is a reply to message #421033] Tue, 05 August 2008 13:22 Go to previous messageGo to next message
samuel is currently offline samuelFriend
Messages: 11
Registered: July 2009
Junior Member
I found the solution of my problem, but I needed to change some EMF generated Model classes.

Here is a list of modified classes (if my model is named Model):

1. <b>ModelPackageImpl</b>

After the method createPackageContents, I added a method to dynamically detect classes overridden and replace the base EClass by the overridden ones.

2. <b>Each model class Impl</b> extends now DynamicEObjectImpl instead of BasicEObjectImpl




Now I am able to do things like this:

//Creation Test
Resource generatedModelClass = ecoreHelper.getModelFactory().createResource();//
EClass eClass = generatedModelClass.eClass(); assertTrue(eClass.getName().equals("ResourceExtendedTest"));// The eclass has been dynamically overriden

//Test generated Setter&Getter
final String name = "TestName";
generatedModelClass.setName(name);
assertEquals(generatedModelClass.getName(), name);


//Test extended attribute :
EAttribute extendedAttribute = eClass.getEAttributes().get(0);
assertTrue(extendedAttribute.getName().equals("additionalAttribute "));
generatedModelClass.eSet(extendedAttribute, true);
assertTrue((Boolean)generatedModelClass.eGet(extendedAttribu te));
generatedModelClass.eSet(extendedAttribute, false);
assertFalse((Boolean)generatedModelClass.eGet(extendedAttrib ute));



Now it would be great to modify the JET templates in order to directly generate the modified code.
In the genmodel, I found an option to specify if the class is dynamic, but when activating this option, the models classes are not generated.
So maybe a mixed dynamic/static option can be added ?
I don't really know where the JET templates are located, so if someone can point me out, I would be thankful.

Regards,

Samuel
Re: EMF generated POJO containing dynamically overridden EClass [message #421357 is a reply to message #421356] Tue, 05 August 2008 13:56 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Samuel,

Comments below.

Samuel wrote:
> I found the solution of my problem, but I needed to change some EMF generated Model classes.
>
> Here is a list of modified classes (if my model is named Model):
>
> 1. <b>ModelPackageImpl</b>
>
> After the method createPackageContents, I added a method to dynamically detect classes overridden and replace the base EClass by the overridden ones.
>
I don't get what this means.
> 2. <b>Each model class Impl</b> extends now DynamicEObjectImpl instead of BasicEObjectImpl
>
>
>
>
> Now I am able to do things like this:
>
> //Creation Test
> Resource generatedModelClass = ecoreHelper.getModelFactory().createResource();//
> EClass eClass = generatedModelClass.eClass(); assertTrue(eClass.getName().equals("ResourceExtendedTest"));// The eclass has been dynamically overriden
>
> //Test generated Setter&Getter
> final String name = "TestName";
> generatedModelClass.setName(name);
> assertEquals(generatedModelClass.getName(), name);
>
>
> //Test extended attribute :
> EAttribute extendedAttribute = eClass.getEAttributes().get(0);
> assertTrue(extendedAttribute.getName().equals("additionalAttribute "));
> generatedModelClass.eSet(extendedAttribute, true);
> assertTrue((Boolean)generatedModelClass.eGet(extendedAttribu te));
> generatedModelClass.eSet(extendedAttribute, false);
> assertFalse((Boolean)generatedModelClass.eGet(extendedAttrib ute));
>
I'm really not following what's special here.
>
>
> Now it would be great to modify the JET templates in order to directly generate the modified code.
> In the genmodel, I found an option to specify if the class is dynamic, but when activating this option, the models classes are not generated.
> So maybe a mixed dynamic/static option can be added ?
> I don't really know where the JET templates are located, so if someone can point me out, I would be thankful.
>
The templates are in org.eclipse.emf.codegen.ecore/templates.

Maybe you want to provide a more complete outline of what you've done
and what you're trying to accomplish so I can understand if that's the
best approach and whether there might be simpler ways to accomplish your
goal.
> Regards,
>
> Samuel
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF generated POJO containing dynamically overridden EClass [message #421611 is a reply to message #421357] Mon, 11 August 2008 14:00 Go to previous messageGo to next message
samuel is currently offline samuelFriend
Messages: 11
Registered: July 2009
Junior Member
Thanks for your answer !

Of course, there is nothing special about the code I showed, except that the dynamic attributes ( eSet ) has been added after...

I'll try to reformulate the problem:

We want to provide to our customer a java application (compiled in a jar), and an ecore file plus some ocl rules.

The client can modify the ecore file and extends some classes we don't know in advance. Ex, we have a BasicMessage class in the ecore, and the client add his own ClientMessage class extending the basic one, with specific attributes (used only in the customized ocl rules).
When we load the class (from DB, thanks teneo), we want to load the extended ClientMessage, so the factory need to detect that our BasicMessage has been overidded.


I hope it's more clear now, but explaining it again make me realize that it's very specific to our needs, and I'm not sure it can be generalized for everybody.
Re: EMF generated POJO containing dynamically overridden EClass [message #421612 is a reply to message #421611] Mon, 11 August 2008 15:15 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Samuel,

Comments below.


Samuel Michelot wrote:
> Thanks for your answer !
>
> Of course, there is nothing special about the code I showed, except that the dynamic attributes ( eSet ) has been added after...
>
> I'll try to reformulate the problem:
>
> We want to provide to our customer a java application (compiled in a jar), and an ecore file plus some ocl rules.
>
> The client can modify the ecore file and extends some classes we don't know in advance.
Modifying the Ecore is not a good way to think about it in my opinion.
The customer could extend your Ecore model with classes of their own,
but your best to think of the base classes as immutable once you
generate them. Of course a base class can have features that are
inherently extensible. I.e., many models provide support for being able
to decorate or annotate the base instance. XML Schema also provides
things like wildcards and even substitution groups that allow a "derived
schema/model" to inject information into a base one.
> Ex, we have a BasicMessage class in the ecore, and the client add his own ClientMessage class extending the basic one, with specific attributes (used only in the customized ocl rules).
>
So extending classes is cool. That's already supported. It's even
possible for a dynamic model (one for which no code is generated) to
extend a base generated model...
> When we load the class (from DB, thanks teneo), we want to load the extended ClientMessage, so the factory need to detect that our BasicMessage has been overidded.
>
If you saved a ClientMessage instance you should get one back. It
should also be possible to copy the data from a BasicMessage to an
extended ClientMessage. But I'm not sure you should be expecting a
stored BasicMessage to surface as a ClientMessage...
>
> I hope it's more clear now, but explaining it again make me realize that it's very specific to our needs, and I'm not sure it can be generalized for everybody.
>
I think you should try to make it work with the established approaches.
It seems to me the client should just develop an extended model...


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF generated POJO containing dynamically overridden EClass [message #421797 is a reply to message #421612] Wed, 13 August 2008 16:12 Go to previous messageGo to next message
samuel is currently offline samuelFriend
Messages: 11
Registered: July 2009
Junior Member
Of course "the base classes as immutable once you
generate them".
-> the clients does't really modify the ecore file, but make another ecore (with a link to the base ecore). It was to simplify my explanation.



"If you saved a ClientMessage instance you should get one back. It
should also be possible to copy the data from a BasicMessage to an
extended ClientMessage. But I'm not sure you should be expecting a
stored BasicMessage to surface as a ClientMessage... "

-> Of course I can explicitely a ClientMessage, but for that, I need to create a ClientMessage, so the factory need to know that the basic Message has been extended. So the factory HAS to be modified.

I am still not convinced that I can work with the estabished aproach. I thougt it before, but after some testing & prototyping, I realized that it wasn't possible.

Thanks for your help !
Re: EMF generated POJO containing dynamically overridden EClass [message #421799 is a reply to message #421797] Wed, 13 August 2008 18:32 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050007030208070305000405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Samuel,

A factory should create an instance of exactly the type of object for
which it is a factory. I.e., One should always expect that
EcoreUtil.create(eClass).eClass() == eClass will be true. This blog
seems somewhat related:
< http://ed-merks.blogspot.com/2008/01/creating-children-you-d idnt-know.html>


http://ed-merks.blogspot.com/2008/01/creating-children-you-d idnt-know.html


Samuel Michelot wrote:
> Of course "the base classes as immutable once you
> generate them".
> -> the clients does't really modify the ecore file, but make another ecore (with a link to the base ecore). It was to simplify my explanation.
>
>
>
> "If you saved a ClientMessage instance you should get one back. It
> should also be possible to copy the data from a BasicMessage to an
> extended ClientMessage. But I'm not sure you should be expecting a
> stored BasicMessage to surface as a ClientMessage... "
>
> -> Of course I can explicitely a ClientMessage, but for that, I need to create a ClientMessage, so the factory need to know that the basic Message has been extended. So the factory HAS to be modified.
>
> I am still not convinced that I can work with the estabished aproach. I thougt it before, but after some testing & prototyping, I realized that it wasn't possible.
>
> Thanks for your help !
>

--------------050007030208070305000405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Samuel,<br>
<br>
A factory should create an instance of exactly the type of object for
which it is a factory.&nbsp; I.e., One should always expect that
EcoreUtil.create(eClass).eClass() == eClass will be true. &nbsp; This blog
seems somewhat related:<a
href=" http://ed-merks.blogspot.com/2008/01/creating-children-you-d idnt-know.html"><br>
</a>
<blockquote><a
href=" http://ed-merks.blogspot.com/2008/01/creating-children-you-d idnt-know.html"> http://ed-merks.blogspot.com/2008/01/creating-children-you-d idnt-know.html</a><br>
</blockquote>
<br>
Samuel Michelot wrote:
<blockquote
cite="mid:7338813.33711218643969628.JavaMail.root@cp1.dzone.com"
type="cite">
<pre wrap="">Of course "the base classes as immutable once you
generate them".
-&gt; the clients does't really modify the ecore file, but make another ecore (with a link to the base ecore). It was to simplify my explanation.



"If you saved a ClientMessage instance you should get one back. It
should also be possible to copy the data from a BasicMessage to an
extended ClientMessage. But I'm not sure you should be expecting a
stored BasicMessage to surface as a ClientMessage... "

-&gt; Of course I can explicitely a ClientMessage, but for that, I need to create a ClientMessage, so the factory need to know that the basic Message has been extended. So the factory HAS to be modified.

I am still not convinced that I can work with the estabished aproach. I thougt it before, but after some testing &amp; prototyping, I realized that it wasn't possible.

Thanks for your help !
</pre>
</blockquote>
</body>
</html>

--------------050007030208070305000405--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF generated POJO containing dynamically overridden EClass [message #421845 is a reply to message #421799] Thu, 14 August 2008 13:54 Go to previous messageGo to next message
samuel is currently offline samuelFriend
Messages: 11
Registered: July 2009
Junior Member
&gt; <br>
&gt; A factory should create an instance of exactly the
&gt; type of object for
&gt; which it is a factory.&nbsp; I.e., One should always
&gt; expect that
&gt; EcoreUtil.create(eClass).eClass() == eClass will be
&gt; true. &nbsp; This blog
&gt; seems somewhat related:<a
&gt; href="http://ed-merks.blogspot.com/2008/01/creating-c
&gt; ildren-you-didnt-know.html"><br>
&gt; </a>
&gt; <blockquote><a
&gt; href="http://ed-merks.blogspot.com/2008/01/creating-c
&gt; ildren-you-didnt-know.html">http://ed-merks.blogspot.c
&gt; om/2008/01/creating-children-you-didnt-know.html</a><b
&gt; r>
&gt; </blockquote>
&gt; <br>

You are right, with my modifications, EcoreUtil.create(eClass).eClass() != eClass, is that a problem ? Now I can't really trust my implementation, and I run into some problems when dealing with ocl and extended problem, and I am not sure if it's come from those modifications :-(

Thanks Ed for pointing me out your blog entry. It looks interresting for my problem, Especially the bug
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=109472">, but it's look like it still requiered code generation when the model is extended. Am I wrong ?
Now I am a little confused about the right thing to do...
Can you point me out the best way to do what I need? Don't hesitate to ask me a more complete explanation of my needs..
Re: EMF generated POJO containing dynamically overridden EClass [message #421848 is a reply to message #421845] Thu, 14 August 2008 14:09 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Samuel,

Comments below.

Samuel Michelot wrote:
> &gt; <br>
> &gt; A factory should create an instance of exactly the
> &gt; type of object for
> &gt; which it is a factory.&nbsp; I.e., One should always
> &gt; expect that
> &gt; EcoreUtil.create(eClass).eClass() == eClass will be
> &gt; true. &nbsp; This blog
> &gt; seems somewhat related:<a
> &gt; href="http://ed-merks.blogspot.com/2008/01/creating-c
> &gt; ildren-you-didnt-know.html"><br>
> &gt; </a>
> &gt; <blockquote><a
> &gt; href="http://ed-merks.blogspot.com/2008/01/creating-c
> &gt; ildren-you-didnt-know.html">http://ed-merks.blogspot.c
> &gt; om/2008/01/creating-children-you-didnt-know.html</a><b
> &gt; r>
> &gt; </blockquote>
> &gt; <br>
>
> You are right, with my modifications, EcoreUtil.create(eClass).eClass() != eClass, is that a problem ? Now I can't really trust my implementation, and I run into some problems when dealing with ocl and extended problem, and I am not sure if it's come from those modifications :-(
>
> Thanks Ed for pointing me out your blog entry. It looks interresting for my problem, Especially the bug
> <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=109472">, but it's look like it still requiered code generation when the model is extended. Am I wrong ?
>
Yes, the extenders are generated. ReflectiveItemProviderAdapter works
for all EObject and it has methods to gather up all the classes so it's
able to be smarter about picking up children from all models it knows
about... I've never tried making a generated item provider extend that
implementation class as the base (which is configurable in the GenModel).
> Now I am a little confused about the right thing to do...
> Can you point me out the best way to do what I need?
Tell your clients to generate their extended model. :-P
> Don't hesitate to ask me a more complete explanation of my needs..
>
If you need something more dynamic and this is mostly about making sure
the editor provides the extended choices, definitely looking at
ReflectiveItemProviderAdapter is a good idea.


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:Initialize genmodel values
Next Topic:Set<K> vs Map
Goto Forum:
  


Current Time: Fri Mar 29 02:29:06 GMT 2024

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

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

Back to the top