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  |
 Hallvard Traetteberg
Messages: 673
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  |
Ed Merks
Messages: 33140
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| 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 |
Hallvard Traetteberg
Messages: 673
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
|
|
|
Goto Forum:
Current Time: Tue Apr 23 11:10:19 GMT 2024
Powered by FUDForum. Page generated in 0.02750 seconds |
] 
Search
Help
Register
Login
Home
