|
|
Re: Ecore: Type parameter for interface implementation? [message #1787635 is a reply to message #1787632] |
Wed, 30 May 2018 11:20 |
Jens Bürger Messages: 55 Registered: October 2012 |
Member |
|
|
Thanks for your quick reply,
Ed Willink wrote on Wed, 30 May 2018 06:40Hi
The GenModel Root extends/implements Class/Interface options seem to do what you are looking for. Can you explain why they don't work for you?
Ed Willink wrote on Wed, 30 May 2018 06:40
And, can you explain your problem much more clearly. I'm not clear what you mean by the feature "Operation" or why it might help solve your problem.
With "operation" I mean the function of adding an operation (i.e. method) to an Eclass. This apparently cannot solve my problem because one Eclass can only have one implementation which then also is not part of the model instantiation.
Basically, I want to combinate to things:
1. some kind of domain model (as Ecore) that manages knowledge and processes how to manipulate a number of given data sources and under which circumstances.
2. a number of Java classes which implement behaviour that is needed for (parts of) the data manipulation code from 1.
In the example, the classes mentioned in 2. all implement the interface ISem.
So my idea is to have an Eclass which points to a Java class. This should generally be possible adding an attribute with the predefined datatype "EJavaClass".
So I added a Eclass "ESem" to the model including an attribute "mySem: EJavaClass".
But this lets Eclipse generate code with a generic property "Class", which lets it point to virtually any valid Java class.
I want to restrict this so that only classes can be used that implement the interface ISem.
I thought that defining a type parameter (i.e., shown as the light gray dashed box attached to an Eclass in the Ecore diagram editor) would be the way to go, but that leads to generated code defining
This doesn't help because a class, be it "SemA" which implements ISem does not have the type ISem but matches , right?
So what I want to know: is there a way to get to this variant, and which modifications I need to make to the Ecore?
Regarding the genmodel options you mentioned: this would apply to all classes in the Ecore model, right?
|
|
|
|
Re: Ecore: Type parameter for interface implementation? [message #1787644 is a reply to message #1787641] |
Wed, 30 May 2018 11:45 |
Jens Bürger Messages: 55 Registered: October 2012 |
Member |
|
|
Ed Willink wrote on Wed, 30 May 2018 07:32
Perhaps a 'UML' diagram might make everything clear.
Sure!
Here we go.
I attached an example which hopefully makes clear what I am trying to accomplish.
In this example, I want to manage a catalog of security checks. Every security check may have a number of security controls.
While, in turn, every security control is carried out by executing code, available as Java classes which all implement the "ISem" interface.
[Updated on: Wed, 30 May 2018 11:51] Report message to a moderator
|
|
|
|
|
|
|
|
Re: Ecore: Type parameter for interface implementation? [message #1790541 is a reply to message #1790277] |
Tue, 12 June 2018 15:18 |
Jens Bürger Messages: 55 Registered: October 2012 |
Member |
|
|
Ed Merks wrote on Thu, 07 June 2018 14:44DanglingHREFException is answered in the FAQ and has nothing to do with using generics:
Correct. As I wrote, the original problem is solved now but the DanglingHREFException is a new problem I face when trying to save the model.
Ed Merks wrote on Thu, 07 June 2018 14:44
EJavaClass instances already support serialization,
...
so I'm not sure what problem you're having with that.
The problem apparently is that the classes (in my example, a number of classes with the type <? extends ISem>) I have are not part of the resource.
I understand that this is because they are not part of the Ecore model but only referenced by "mySem" attributes.
If I understand the FAQ you mentioned right, only EObjects can be and need to be added to the resource, but the classes I want to refer to are pure Java classes.
The model code generated for the My.ecore from my last post also generates pure Java class attributes and no EJavaclass:
public class SemImpl extends MinimalEObjectImpl.Container implements Sem {
/**
* The cached value of the '{@link #getMySem() <em>My Sem</em>}' attribute.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @see #getMySem()
* @generated
* @ordered
*/
protected Class<? extends ISem> mySem;
...
So, the questions are:
1) Is it possible to have a Ecore model reference pure Java classes and persist it? What actions need to take place then so that the classes are part of the resource and no DanglingHREFException comes up?
2) If not, what changes need to be made to be made to the Ecore/the classes then?
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03856 seconds