Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Jimmy Royer is currently offline Jimmy RoyerFriend
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
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 #423160 is a reply to message #423153] Tue, 23 September 2008 23:37 Go to previous messageGo to next message
Jimmy Royer is currently offline Jimmy RoyerFriend
Messages: 16
Registered: July 2009
Junior Member
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..

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.

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. 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.

Thanks for your help,
Jimmy
Re: Editing a generic attribute in the property sheet pane [message #423161 is a reply to message #423160] Tue, 23 September 2008 23:43 Go to previous message
Ed Merks is currently offline Ed MerksFriend
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/
Previous Topic:Problems reloading a new XML schema
Next Topic:improve resource loading performance
Goto Forum:
  


Current Time: Fri Mar 29 08:48:29 GMT 2024

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

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

Back to the top