Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Problem in edit plugin when subclassing from Ecore
Problem in edit plugin when subclassing from Ecore [message #402934] Fri, 11 August 2006 12:52 Go to next message
Victor Sanchez is currently offline Victor Sanchez
Messages: 28
Registered: July 2009
Junior Member
Hello!

I know that it is not advisable to subclass Ecore, but once I did this I
had problems to navigate models in the Sample Ecore Editor, concretely
with the Properties view. This happens in EMF v2.2.0.

The Item Provider for an EClass that subclasses directly from an Ecore
element lists in its generated 'getPropertyDescriptors' method all the
inherited properties from the Ecore element, together with the ones that
specifically belong to it. The properties are added sequentially through
independent methods whose name is 'add<property_nm>PropertyDescriptor'.

The problem is that those properties that are inherited from an Ecore
element are referencing string such as '_UI_ENamedElement_type' or
'_UI_ENamedElement_name_feature', but these are missing from the
'plugin.properties' generated file in the Edit plugin, so in the
Properties View nothing appeared at all when selecting objects of the
affected types.

In order for the .genmodel to work I have had to change the textual
references to Ecore in the .ecore model by hand from
'eSuperTypes=" ../../../plugin/org.eclipse.emf.ecore/model/Ecore.ecore#...'
to 'eSuperTypes="http://www.eclipse.org/emf/2002/Ecore#...', so otherwise
I wouldn't come up with the abovementioned problem.

What I was wondering is whether the code generation should be more
consistent with these circumstances and either:

1.- automatically include the missing strings in the
'plugin.properties' file or
2.- eliminate the conflicting property descriptor additions for the
'<type>ItemProvider' files, which I suppose is an unacceptable solution.

Thanks
Victor
Re: Problem in edit plugin when subclassing from Ecore [message #402936 is a reply to message #402934] Fri, 11 August 2006 13:46 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26152
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000502090901040102070001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Victor,

I would expect the generated .edit plugin's plugin class to include a
reference to the EcoreEditPlugin's instance like UML2's edit plugin
class does:

/**
* Create the instance.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated NOT
*/
public UMLEditPlugin() {
super(new ResourceLocator[]{*EcoreEditPlugin.INSTANCE*,
EMFEditPlugin.INSTANCE});
}

This will result in delegation during property lookup.


Victor Sanchez wrote:
> Hello!
>
> I know that it is not advisable to subclass Ecore, but once I did this I
> had problems to navigate models in the Sample Ecore Editor, concretely
> with the Properties view. This happens in EMF v2.2.0.
>
> The Item Provider for an EClass that subclasses directly from an Ecore
> element lists in its generated 'getPropertyDescriptors' method all the
> inherited properties from the Ecore element, together with the ones that
> specifically belong to it. The properties are added sequentially through
> independent methods whose name is 'add<property_nm>PropertyDescriptor'.
>
> The problem is that those properties that are inherited from an Ecore
> element are referencing string such as '_UI_ENamedElement_type' or
> '_UI_ENamedElement_name_feature', but these are missing from the
> 'plugin.properties' generated file in the Edit plugin, so in the
> Properties View nothing appeared at all when selecting objects of the
> affected types.
>
> In order for the .genmodel to work I have had to change the textual
> references to Ecore in the .ecore model by hand from
> 'eSuperTypes=" ../../../plugin/org.eclipse.emf.ecore/model/Ecore.ecore#...'
> to 'eSuperTypes="http://www.eclipse.org/emf/2002/Ecore#...', so otherwise
> I wouldn't come up with the abovementioned problem.
>
> What I was wondering is whether the code generation should be more
> consistent with these circumstances and either:
>
> 1.- automatically include the missing strings in the
> 'plugin.properties' file or
> 2.- eliminate the conflicting property descriptor additions for the
> '<type>ItemProvider' files, which I suppose is an unacceptable solution.
>
> Thanks
> Victor
>
>
>


--------------000502090901040102070001
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">
Victor,<br>
<br>
I would expect the generated .edit plugin's plugin class to include a
reference to the EcoreEditPlugin's instance like UML2's edit plugin
class does:<br>
<blockquote>&nbsp;&nbsp;&nbsp; /**<br>
&nbsp;&nbsp;&nbsp; &nbsp;* Create the instance.<br>
&nbsp;&nbsp;&nbsp; &nbsp;* &lt;!-- begin-user-doc --&gt;<br>
&nbsp;&nbsp;&nbsp; &nbsp;* &lt;!-- end-user-doc --&gt;<br>
&nbsp;&nbsp;&nbsp; &nbsp;* @generated NOT<br>
&nbsp;&nbsp;&nbsp; &nbsp;*/<br>
&nbsp;&nbsp;&nbsp; public UMLEditPlugin() {<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; super(new ResourceLocator[]{<b>EcoreEditPlugin.INSTANCE</b>,<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; EMFEditPlugin.INSTANCE});<br>
&nbsp;&nbsp;&nbsp; }<br>
</blockquote>
This will result in delegation during property lookup.<br>
<br>
<br>
Victor Sanchez wrote:
<blockquote cite="midpan.2006.08.11.12.51.59.4328@opencanarias.com"
type="cite">
<pre wrap="">Hello!

I know that it is not advisable to subclass Ecore, but once I did this I
had problems to navigate models in the Sample Ecore Editor, concretely
with the Properties view. This happens in EMF v2.2.0.

The Item Provider for an EClass that subclasses directly from an Ecore
element lists in its generated 'getPropertyDescriptors' method all the
inherited properties from the Ecore element, together with the ones that
specifically belong to it. The properties are added sequentially through
independent methods whose name is 'add&lt;property_nm&gt;PropertyDescriptor'.

The problem is that those properties that are inherited from an Ecore
element are referencing string such as '_UI_ENamedElement_type' or
'_UI_ENamedElement_name_feature', but these are missing from the
'plugin.properties' generated file in the Edit plugin, so in the
Properties View nothing appeared at all when selecting objects of the
affected types.

In order for the .genmodel to work I have had to change the textual
references to Ecore in the .ecore model by hand from
'eSuperTypes=" ../../../plugin/org.eclipse.emf.ecore/model/Ecore.ecore#...'
to 'eSuperTypes="<a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore#">http://www.eclipse.org/emf/2002/Ecore#</a>...', so otherwise
I wouldn't come up with the abovementioned problem.

What I was wondering is whether the code generation should be more
consistent with these circumstances and either:

1.- automatically include the missing strings in the
'plugin.properties' file or
2.- eliminate the conflicting property descriptor additions for the
'&lt;type&gt;ItemProvider' files, which I suppose is an unacceptable solution.

Thanks
Victor


</pre>
</blockquote>
<br>
</body>
</html>

--------------000502090901040102070001--
Re: Problem in edit plugin when subclassing from Ecore [message #402937 is a reply to message #402936] Fri, 11 August 2006 14:31 Go to previous messageGo to next message
Victor Sanchez is currently offline Victor Sanchez
Messages: 28
Registered: July 2009
Junior Member
Thank you very much. I finally only included a reference to the
'EcoreEditPlugin' instance and now the editor works fine.

By the way, is there a reason why this reference is not included
automatically in the generated plugin class?

Best regards!
Victor

On Fri, 11 Aug 2006 09:46:29 -0400, Ed Merks wrote:

> Victor,
>
> I would expect the generated .edit plugin's plugin class to include a
> reference to the EcoreEditPlugin's instance like UML2's edit plugin
> class does:
>
> /**
> * Create the instance.
> * <!-- begin-user-doc -->
> * <!-- end-user-doc -->
> * @generated NOT
> */
> public UMLEditPlugin() {
> super(new ResourceLocator[]{*EcoreEditPlugin.INSTANCE*,
> EMFEditPlugin.INSTANCE});
> }
>
> This will result in delegation during property lookup.
Re: Problem in edit plugin when subclassing from Ecore [message #402941 is a reply to message #402937] Fri, 11 August 2006 15:02 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26152
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------080707010000080003070608
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Victor,

I wondered about that too. Perhaps because all models depend on Ecore's
types we filter Ecore out which we shouldn't do if Ecore's classes are
being extended, but then we recommend folks not do that. If you can
provide a small example to illustrate the issue, we can look into fixing
it. Yes, I'm too lazy, I mean busy, to make one. ;-)


Victor Sanchez wrote:
> Thank you very much. I finally only included a reference to the
> 'EcoreEditPlugin' instance and now the editor works fine.
>
> By the way, is there a reason why this reference is not included
> automatically in the generated plugin class?
>
> Best regards!
> Victor
>
> On Fri, 11 Aug 2006 09:46:29 -0400, Ed Merks wrote:
>
>
>> Victor,
>>
>> I would expect the generated .edit plugin's plugin class to include a
>> reference to the EcoreEditPlugin's instance like UML2's edit plugin
>> class does:
>>
>> /**
>> * Create the instance.
>> * <!-- begin-user-doc -->
>> * <!-- end-user-doc -->
>> * @generated NOT
>> */
>> public UMLEditPlugin() {
>> super(new ResourceLocator[]{*EcoreEditPlugin.INSTANCE*,
>> EMFEditPlugin.INSTANCE});
>> }
>>
>> This will result in delegation during property lookup.
>>
>
>
>


--------------080707010000080003070608
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">
Victor,<br>
<br>
I wondered about that too.&nbsp; Perhaps because all models depend on
Ecore's types we filter Ecore out which we shouldn't do if Ecore's
classes are being extended, but then we recommend folks not do that.&nbsp;
If you can provide a small example to illustrate the issue, we can look
into fixing it.&nbsp; Yes, I'm too lazy, I mean busy, to make one. ;-)<br>
<br>
<br>
Victor Sanchez wrote:
<blockquote cite="midpan.2006.08.11.14.31.30.268400@opencanarias.com"
type="cite">
<pre wrap="">Thank you very much. I finally only included a reference to the
'EcoreEditPlugin' instance and now the editor works fine.

By the way, is there a reason why this reference is not included
automatically in the generated plugin class?

Best regards!
Victor

On Fri, 11 Aug 2006 09:46:29 -0400, Ed Merks wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Victor,

I would expect the generated .edit plugin's plugin class to include a
reference to the EcoreEditPlugin's instance like UML2's edit plugin
class does:

/**
* Create the instance.
* &lt;!-- begin-user-doc --&gt;
* &lt;!-- end-user-doc --&gt;
* @generated NOT
*/
public UMLEditPlugin() {
super(new ResourceLocator[]{*EcoreEditPlugin.INSTANCE*,
EMFEditPlugin.INSTANCE});
}

This will result in delegation during property lookup.
</pre>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
<br>
</body>
</html>

--------------080707010000080003070608--
Re: Problem in edit plugin when subclassing from Ecore [message #402948 is a reply to message #402941] Fri, 11 August 2006 16:22 Go to previous messageGo to next message
Victor Sanchez is currently offline Victor Sanchez
Messages: 28
Registered: July 2009
Junior Member
Ok, I know what the problem is. I've based the test on a single EClass
contained in an EPackage and ENamedElement as its ESuper Type.

When editing the .genmodel an Ecore EPackage dependency is shown under
the main package, and under these circumstances the generated .edit
plugin's plugin class includes the dependency with the Ecore Edit
plugin as expected:

/**
* Create the instance.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public TempEditPlugin() {
super
(new ResourceLocator [] {
EcoreEditPlugin.INSTANCE,
});
}

Now I put my hands directly upon the .ecore file text and change the
reference to the super type ENamedElement from:

'eSuperTypes=" ../../../plugin/org.eclipse.emf.ecore/model/Ecore.ecore#...'

to

'eSuperTypes="http://www.eclipse.org/emf/2002/Ecore#...'

and a similar change is performed on the .genmodel file for the
'usedGenPackages' property so it now has the following value:

'usedGenPackages="http://www.eclipse.org/emf/2002/GenModel#//ecore">'

Just after this last modification, the genmodel file is no longer
showing the Ecore dependency in the Sample Ecore Editor, and at the same
time, the edit plugin generation is now missing the Ecore Edit plugin
instance in the resource locator of the 'TempEditPlugin' constructor.

Regards!
Victor


On Fri, 11 Aug 2006 11:02:55 -0400, Ed Merks wrote:

> Victor,
>
> I wondered about that too. Perhaps because all models depend on Ecore's
> types we filter Ecore out which we shouldn't do if Ecore's classes are
> being extended, but then we recommend folks not do that. If you can
> provide a small example to illustrate the issue, we can look into fixing
> it. Yes, I'm too lazy, I mean busy, to make one. ;-)
>
>
> Victor Sanchez wrote:
>> Thank you very much. I finally only included a reference to the
>> 'EcoreEditPlugin' instance and now the editor works fine.
>>
>> By the way, is there a reason why this reference is not included
>> automatically in the generated plugin class?
>>
>> Best regards!
>> Victor
>>
>> On Fri, 11 Aug 2006 09:46:29 -0400, Ed Merks wrote:
>>
>>
Re: Problem in edit plugin when subclassing from Ecore [message #402950 is a reply to message #402948] Fri, 11 August 2006 16:43 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26152
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010300050005000907000906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Victor,

If you extend the Ecore types, it's important to use the version of
Ecore with an associated GenModel so that you will pick up all the
GenModel settings for the Ecore model (such as the bit flags setting).
I.e., you really should use

org.eclipse.emf.ecore/model/Ecore.ecore

if you are extending Ecore and you are likely run into problems if you
don't (as you're seeing already)...


Victor Sanchez wrote:
> Ok, I know what the problem is. I've based the test on a single EClass
> contained in an EPackage and ENamedElement as its ESuper Type.
>
> When editing the .genmodel an Ecore EPackage dependency is shown under
> the main package, and under these circumstances the generated .edit
> plugin's plugin class includes the dependency with the Ecore Edit
> plugin as expected:
>
> /**
> * Create the instance.
> * <!-- begin-user-doc -->
> * <!-- end-user-doc -->
> * @generated
> */
> public TempEditPlugin() {
> super
> (new ResourceLocator [] {
> EcoreEditPlugin.INSTANCE,
> });
> }
>
> Now I put my hands directly upon the .ecore file text and change the
> reference to the super type ENamedElement from:
>
> 'eSuperTypes=" ../../../plugin/org.eclipse.emf.ecore/model/Ecore.ecore#...'
>
> to
>
> 'eSuperTypes="http://www.eclipse.org/emf/2002/Ecore#...'
>
> and a similar change is performed on the .genmodel file for the
> 'usedGenPackages' property so it now has the following value:
>
> 'usedGenPackages="http://www.eclipse.org/emf/2002/GenModel#//ecore">'
>
> Just after this last modification, the genmodel file is no longer
> showing the Ecore dependency in the Sample Ecore Editor, and at the same
> time, the edit plugin generation is now missing the Ecore Edit plugin
> instance in the resource locator of the 'TempEditPlugin' constructor.
>
> Regards!
> Victor
>
>
> On Fri, 11 Aug 2006 11:02:55 -0400, Ed Merks wrote:
>
>
>> Victor,
>>
>> I wondered about that too. Perhaps because all models depend on Ecore's
>> types we filter Ecore out which we shouldn't do if Ecore's classes are
>> being extended, but then we recommend folks not do that. If you can
>> provide a small example to illustrate the issue, we can look into fixing
>> it. Yes, I'm too lazy, I mean busy, to make one. ;-)
>>
>>
>> Victor Sanchez wrote:
>>
>>> Thank you very much. I finally only included a reference to the
>>> 'EcoreEditPlugin' instance and now the editor works fine.
>>>
>>> By the way, is there a reason why this reference is not included
>>> automatically in the generated plugin class?
>>>
>>> Best regards!
>>> Victor
>>>
>>> On Fri, 11 Aug 2006 09:46:29 -0400, Ed Merks wrote:
>>>
>>>
>>>
>
>


--------------010300050005000907000906
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">
Victor,<br>
<br>
If you extend the Ecore types, it's important to use the version of
Ecore with an associated GenModel so that you will pick up all the
GenModel settings for the Ecore model (such as the bit flags setting).
&nbsp; I.e., you really should use<br>
<blockquote>
<pre wrap="">org.eclipse.emf.ecore/model/Ecore.ecore</pre>
</blockquote>
if you are extending Ecore and you are likely run into problems if you
don't (as you're seeing already)...<br>
<br>
<br>
Victor Sanchez wrote:
<blockquote cite="midpan.2006.08.11.16.22.43.874663@opencanarias.com"
type="cite">
<pre wrap="">Ok, I know what the problem is. I've based the test on a single EClass
contained in an EPackage and ENamedElement as its ESuper Type.

When editing the .genmodel an Ecore EPackage dependency is shown under
the main package, and under these circumstances the generated .edit
plugin's plugin class includes the dependency with the Ecore Edit
plugin as expected:

/**
* Create the instance.
* &lt;!-- begin-user-doc --&gt;
* &lt;!-- end-user-doc --&gt;
* @generated
*/
public TempEditPlugin() {
super
(new ResourceLocator [] {
EcoreEditPlugin.INSTANCE,
});
}

Now I put my hands directly upon the .ecore file text and change the
reference to the super type ENamedElement from:

'eSuperTypes=" ../../../plugin/org.eclipse.emf.ecore/model/Ecore.ecore#...'

to

'eSuperTypes=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/emf/2002/Ecore#... 'andasimilarchangeisperformedonthe.genmodelfileforthe'usedGe nPackages'propertysoitnowhasthefollowingvalue:'usedGenPackag es= ">"http://www.eclipse.org/emf/2002/Ecore#...'

and a similar change is performed on the .genmodel file for the
'usedGenPackages' property so it now has the following value:

'usedGenPackages="</a<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/emf/2002/GenModel#//ecore">"http://www.eclipse.org/emf/2002/GenModel#//ecore"</a>&gt;'

Just after this last modification, the genmodel file is no longer
showing the Ecore dependency in the Sample Ecore Editor, and at the same
time, the edit plugin generation is now missing the Ecore Edit plugin
instance in the resource locator of the 'TempEditPlugin' constructor.

Regards!
Victor


On Fri, 11 Aug 2006 11:02:55 -0400, Ed Merks wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Victor,

I wondered about that too. Perhaps because all models depend on Ecore's
types we filter Ecore out which we shouldn't do if Ecore's classes are
being extended, but then we recommend folks not do that. If you can
provide a small example to illustrate the issue, we can look into fixing
it. Yes, I'm too lazy, I mean busy, to make one. ;-)


Victor Sanchez wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Thank you very much. I finally only included a reference to the
'EcoreEditPlugin' instance and now the editor works fine.

By the way, is there a reason why this reference is not included
automatically in the generated plugin class?

Best regards!
Victor

On Fri, 11 Aug 2006 09:46:29 -0400, Ed Merks wrote:


</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>

--------------010300050005000907000906--
Re: Problem in edit plugin when subclassing from Ecore [message #402951 is a reply to message #402950] Fri, 11 August 2006 17:11 Go to previous message
Victor Sanchez is currently offline Victor Sanchez
Messages: 28
Registered: July 2009
Junior Member
Ok. My problem did probably arise in the first place because of the
..ecore and .genmodel files I was using, which were generated with an older
EMF version (2.0.X, I think).

Thank you, Ed.

On Fri, 11 Aug 2006 12:43:54 -0400, Ed Merks wrote:

> Victor,
>
> If you extend the Ecore types, it's important to use the version of
> Ecore with an associated GenModel so that you will pick up all the
> GenModel settings for the Ecore model (such as the bit flags setting).
> I.e., you really should use
>
> org.eclipse.emf.ecore/model/Ecore.ecore
>
> if you are extending Ecore and you are likely run into problems if you
> don't (as you're seeing already)...
Previous Topic:Attribute - File Browser
Next Topic:stereotypes in Rose mapping to ecore elements
Goto Forum:
  


Current Time: Fri Oct 31 13:02:19 GMT 2014

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

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