Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Property editor for generic attribute does not get the type right
Property editor for generic attribute does not get the type right [message #1712150] Wed, 21 October 2015 14:34 Go to next message
Hallvard Traetteberg is currently offline Hallvard TraettebergFriend
Messages: 671
Registered: July 2009
Location: Trondheim, Norway
Senior Member
I have a model with an abstract class taking a type parameter and an
attribute with that type:

SimpleValue<T> {
T value;
}

I then have subclasses StringValue extends SimpleValue<EString>,
NumberValue extends SimpleValue<EBoolean> etc.

When editing the properties of instances of these, it ends up using the
EJavaObject type for editing, and not the specific types EString,
EBoolean etc, i.e. using Java serialization. The ItemPropertyDescriptor
does not delay the computation of the EDataType to use until it has the
actual EObject, so it may use EcoreUtil.getReifiedType, instead of
using the EDataType of the superclass (EJavaObject).

Any obvious solitions to this? Or must I make a special implementation
of ItemPropertyDescriptor that handles this case?

Hallvard
--
Hallvard Trætteberg (hal@xxxxxxxx.no)
Associate Professor, IS group, Dept. of Computer and Information
Science at the
Norwegian Univ. of Science and Technology
Re: Property editor for generic attribute does not get the type right [message #1712210 is a reply to message #1712150] Thu, 22 October 2015 04:31 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30544
Registered: July 2009
Senior Member
Hallvard,

Yes, it's probably a somewhat tricky issue to resolve. Just at a
glance, things like
org.eclipse.emf.edit.provider.ItemPropertyDescriptor.ItemDelegator.getText(Object)
and
org.eclipse.emf.edit.ui.provider.PropertyDescriptor.createPropertyEditor(Composite)
are impacted. I'm not sure I understand the "delay" aspect of your
comment; mostly the feature is passed around and an instance is passed in...

This clearly has impact on serialization as well and there minimizing
performance impact is paramount.

And I can imagine inconsistencies where the substituted data type isn't
serializable...

Perhaps you'd like to help contribute to base changes to support this
better.


On 21/10/2015 4:34 PM, Hallvard Trætteberg wrote:
> I have a model with an abstract class taking a type parameter and an
> attribute with that type:
>
> SimpleValue<T> {
> T value;
> }
>
> I then have subclasses StringValue extends SimpleValue<EString>,
> NumberValue extends SimpleValue<EBoolean> etc.
>
> When editing the properties of instances of these, it ends up using
> the EJavaObject type for editing, and not the specific types EString,
> EBoolean etc, i.e. using Java serialization. The
> ItemPropertyDescriptor does not delay the computation of the EDataType
> to use until it has the actual EObject, so it may use
> EcoreUtil.getReifiedType, instead of using the EDataType of the
> superclass (EJavaObject).
>
> Any obvious solitions to this? Or must I make a special implementation
> of ItemPropertyDescriptor that handles this case?
>
> Hallvard
Re: Property editor for generic attribute does not get the type right [message #1712234 is a reply to message #1712210] Thu, 22 October 2015 10:13 Go to previous message
Hallvard Traetteberg is currently offline Hallvard TraettebergFriend
Messages: 671
Registered: July 2009
Location: Trondheim, Norway
Senior Member
Ed,

To correctly identify the EDataType, you need both the feature and the
actual object('s eClass). The design can be flawed in two ways: either
computing the EDataType too early, when the actual object isn't known,
or computing it without having access to the object. I'm not sure which
(or both) of these apply here, but the helper objects you refer to seem
to lack knowledge of the actual object, so they cannot use the correct
EDataType. The helper objects must either be created later with
knowledge of the actual object, or the methods for getting the editor
and text must pass in the actual object. Currently, computing the value
to edit seems to be done in two steps: the first gets the feature
value, which of course requires the actual object, while the second
converts it into text suitable for the EDataType. It's the last step
that does not have access to the actual object.

As you say, it's the same issue with serialization, the that is less of
a problem, since the text needn't be understood by a human. Well,
actually, it would be nice to fix that too, for those of us who often
hand-edit XMI files. BTW, I identified and solved this problem for
emfjson's serialization logic and provided a patch/pull request to fix
it. You mention performance, I guess computing the reified type can be
expensive, so the code has to include a fast check to see if it is
necessary.

In my specific case, I could fairly easily change the model to avoid
the problem (I replaced the feature in the superclass by a get method
returning a generic type, and each subclass got its own feature with
the specific type).

Hallvard

On 2015-10-22 04:31:42 +0000, Ed Merks said:
> Hallvard,
>
> Yes, it's probably a somewhat tricky issue to resolve. Just at a
> glance, things like
> org.eclipse.emf.edit.provider.ItemPropertyDescriptor.ItemDelegator.getText(Object)
> and
> org.eclipse.emf.edit.ui.provider.PropertyDescriptor.createPropertyEditor(Composite)
> are impacted. I'm not sure I understand the "delay" aspect of your
> comment; mostly the feature is passed around and an instance is passed
> in...
>
> This clearly has impact on serialization as well and there minimizing
> performance impact is paramount.
>
> And I can imagine inconsistencies where the substituted data type isn't
> serializable...
>
> Perhaps you'd like to help contribute to base changes to support this better.
>
>
> On 21/10/2015 4:34 PM, Hallvard Trætteberg wrote:
>> I have a model with an abstract class taking a type parameter and an
>> attribute with that type:
>>
>> SimpleValue<T> {
>> T value;
>> }
>>
>> I then have subclasses StringValue extends SimpleValue<EString>,
>> NumberValue extends SimpleValue<EBoolean> etc.
>>
>> When editing the properties of instances of these, it ends up using the
>> EJavaObject type for editing, and not the specific types EString,
>> EBoolean etc, i.e. using Java serialization. The ItemPropertyDescriptor
>> does not delay the computation of the EDataType to use until it has the
>> actual EObject, so it may use EcoreUtil.getReifiedType, instead of
>> using the EDataType of the superclass (EJavaObject).
>>
>> Any obvious solitions to this? Or must I make a special implementation
>> of ItemPropertyDescriptor that handles this case?
>>
>> Hallvard


--
Hallvard Trætteberg (hal@xxxxxxxx.no)
Associate Professor, IS group, Dept. of Computer and Information
Science at the
Norwegian Univ. of Science and Technology
Previous Topic:[Xcore] Maven(non tycho)/Gradle sample projects available on github
Next Topic:Child extenders when extending several packages with the same name.
Goto Forum:
  


Current Time: Tue Oct 15 13:42:03 GMT 2019

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

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

Back to the top