[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.tools.emf] Re: Editing a generic attribute in the property sheet pane

Jimmy,

Comments below.


Jimmy Royer wrote:
Hi,

We have a ecore model containing several primitive field types (string, long, int..). On some of these fields, we defined a range restriction on them so that, for example, a long's value should be in between 5 and 10 inclusively.
In XSD you'd model that as a restricted simple type with min/max facets...

Right now, the way it is modeled, we have a Restriction EObject on which several restriction specializations inherit from. One of these specialization is a range restriction. We have a range restriction created for each field type we want it applied on.
This sounds extremely heavy weight.  You could achieve the same thing as with XSD using extended metadata annotations on an EDataType.
For example:


EObject Restriction

EObject LongRangeRestriction extends Restriction
-   EAttribute minimumValue (type ELong)
-   EAttribute maximumValue (type ELong)

EObject IntRangeRestriction extends Restriction
-   EAttribute minimumValue (type EInt)
-   EAttribute maximumValue (type EInt)

EObject Field

EObject Primitive extends Field

EObject Long extends Primitive
-   EAttribute LongRangeRestriction

EObject Int extends Primitive
-   EAttribute IntRangeRestriction


I wanted to generify this structure so that I don't have to repeat the minimumValue/maximumValue attributes in each crafted range restriction. Hence I came up with the following:


EObject Restriction

EObject RangeRestriction<RT extends EJavaObject>
EJavaObject isn't much of a bound...
-   EAttribute minimumValue (type RT)
-   EAttribute maximumValue (type RT)

EObject LongRangeRestriction extends RangeRestriction<ELong>

EObject IntRangeRestriction extends RangeRestriction<EInt>

EObject Field

EObject Primitive inherits from Field

EObject Long inherits from Primitive
-   EAttribute LongRangeRestriction

EObject Int inherits from Primitive
-   EAttribute IntRangeRestriction


Now when I do so, I can't edit the minimumValue/maximumValue attribute values in the property sheet editor of my application anymore.
Which version of EMF are you on?
In fact, when I click on the minimumValue/maximumValue cells to change their value and it is blank, a value will automatically appear, something address-like as "ACED000570".
Probably 2.4 then.  EJavaObject is a very poor data type because it uses java.io.Serializeable to produce a string, which of course isn't human readable.
If I try to put "5" for a IntRangeRestriction, the value disappears after I set it.
And of course it's impossible for a human to enter valid bytes for it too.
Additionally, there is a reported exception in the lower left bar when I start entering some input in the cell, namely "RuntimeException: java.io.EOFException" and "RuntimeException: java.io.StreamCurruptedException: invalid stream handler". Unfortunately, I don't get the complete exception information in my console output.

It seems to me that the usage of ecore generics prevent the correct handling of the specified parameter type for a given RangeRestriction specialization.

* Do I make a valid usage of ecore generics?
You do, but it seems like complete overkill for what you're trying to achieve.

* If it's a valid usage, do you see what I'm doing wrong and how I can fix this?
You're not doing anything wrong, it's just that producing a human readable serialization of something as arbitrary as java.lang.Object isn't feasible...
Do I need to create customized providers for each RangeRestriction specialization to handle the value's type? If so, which method should I overload?
I think you'd be best to define a constrained EDataType.  This document shows the annotations produced from a schema which you can also use directly in your Ecore model:
http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf
The top of page 5 is directly relevant to your problem.

Regards,
Jimmy