Home » Modeling » EMF » Editing a generic attribute in the property sheet pane
Editing a generic attribute in the property sheet pane [message #423144] |
Tue, 23 September 2008 18:39 |
Jimmy Royer Messages: 16 Registered: July 2009 |
Junior Member |
|
|
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.
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. 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>
- 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. 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". If I try to put "5" for a IntRangeRestriction, the value
disappears after I set it. 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?
* If it's a valid usage, do you see what I'm doing wrong and how I can fix
this? Do I need to create customized providers for each RangeRestriction
specialization to handle the value's type? If so, which method should I
overload?
Regards,
Jimmy
|
|
|
Re: Editing a generic attribute in the property sheet pane [message #423153 is a reply to message #423144] |
Tue, 23 September 2008 19:51 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030406060807020909020201
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
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/XMLSchema ToEcoreMapping.pdf
The top of page 5 is directly relevant to your problem.
>
> Regards,
> Jimmy
>
--------------030406060807020909020201
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jimmy,<br>
<br>
Comments below.<br>
<br>
<br>
Jimmy Royer wrote:
<blockquote
cite="mid:cebe0580686f859dfaa7834751c04f85$1@www.eclipse.org"
type="cite">Hi,
<br>
<br>
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.
<br>
</blockquote>
In XSD you'd model that as a restricted simple type with min/max
facets...<br>
<blockquote
cite="mid:cebe0580686f859dfaa7834751c04f85$1@www.eclipse.org"
type="cite"><br>
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. </blockquote>
This sounds extremely heavy weight.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: Editing a generic attribute in the property sheet pane [message #423161 is a reply to message #423160] |
Tue, 23 September 2008 23:43 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
Jimmy.
Comments below.
Jimmy Royer wrote:
> Hi Ed,
>
> First, thanks for your explanation. It's quite helpful. It seems then
> that I won't really be able to leverage generics in this case the way
> I intended, as the serialization happens via the bound type of the
> generic and not on the concrete type of the specialization.
>
> I still wonder though if there is a place where I can take control of
> this serialization. I haven't looked thoroughly..
You can always define your own EDataType, make that the bound, and take
control of how it's serialized. You'd need to come up with something
that serialized not just the value, but enough information to indicate
the type. I.e., is "1" a serialization of an int value or a long value?
>
> Regarding what we try to achieve, it does sound heavyweight as I
> created a sandbox (a heavy one I guess!) of the situation I am in
> without further explanation. My question was really about the
> technical aspect of such an approach.
I see....
> We use ecore for metamodeling purposes. When I was talking about
> primitive types, I was referring to our own modeled primitive types
> that support a specific set of data geared toward strong validation.
I see. I thought it was more specific.
> Our usage of the Restriction objects is a small part of this. Using
> annotation is fine but it seems to me this use case is tailored for
> when you need to keep track of specific information that shouldn't
> pollute the model (such as the EMF use of format mappings between the
> model and the persistence format). I also assume that annotations
> won't provide type safety and we'd really prefer to keep this.
Definitely. The value itself is of a known specific type. It's just
the range of allowed values within that type that's being constrained.
>
> Thanks for your help,
You're welcome. If you can come up with a serialization mechanism that
allows you to create a byte, short, int, long, or whatever bases on the
string value, you can use the type of approach you've shown. I think
this mostly comes down to supporting an enumerated/limited set of types...
> Jimmy
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Mar 29 08:48:29 GMT 2024
Powered by FUDForum. Page generated in 0.06349 seconds
|