Home » Modeling » EMF » Editing a generic attribute in the property sheet pane
|
| Re: Editing a generic attribute in the property sheet pane [message #519594 is a reply to message #519573] |
Tue, 09 March 2010 12:04   |
 Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Ronald,
Comments below.
Ronald wrote:
> I have an ecore model which is going to be used to model cpp threads.
> These threads have several properties, among others a priority.
> I want the user to give the ability to define constraints for the
> propiority using the editor of this ecore model. To achieve this I
> created an class called BoundedPriority which has fields lower and
> upper bound wich are of the type integer just like the value of priority.
>
> However I want to create such a datastructure for some more datatypes
> and therefor I started investigating if generics are usable for this.
> So I wanted to be able to define a generic model for a property in
> which all values are of type E which exteds Type. Type is my own
> typing system which currently only exists of integers.
>
> The goal is to automatically adopt the types of lower and upper bound
> to the type of the value chosen. I have been able to define all of
> this in the ecore model and it seems to generate appropriate java code.
Keep in mind that XML Schema lets you define simple types with these
types of bounds, and EMF can capture those with extended meta data
annotations; maybe you can just reuse that.
>
> However when I use the generated editor, I click on the upper/lower
> bound cells to change their value and it is blank, a value will
> automatically appear, something address-like as "ACED000570". If I put
> a value in, it disappears after I set it.
It sounds like you've not specialized the
createAbcFromString/convertAbcToString in the generated XyzFactoryImpl
for your data type Abc so it's just using java.io.Serializable which
isn't human readable.
>
> My question is, is it possible what I want to achieve?
> From
> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 5219.html
> I learned that it might be necessary to define my own serialization
> method, but can anyone point me to some documentation about how to do
> that?
The first introductory overview talks about data types and specializing
the factory. I'm sure you'll find the method with the hint above.
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | | | |
| Re: Editing a generic attribute in the property sheet pane [message #520117 is a reply to message #520005] |
Thu, 11 March 2010 08:51 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Ed Merks wrote:
>
> Seems reasonable, but keep in mind that EMF like Java defines generics
> in a way where it's generally erased at runtime.
I've encountered a problem which I think is similar. I had an abstract
container class with a type parameter limiting its allowed children:
Container<T extends Component> with a containment reference children
having T as its eType. Specific containers then could limit their
children, e.g. TabFolder<Tab>. This works well when you use the specific
type names like TabFolder in your code, since calls like
getChildren().add/remove can be checked statically. When you instead
write generic code against the Container class, nothing prevents you
from adding other kinds of Components.
I handled this myself by implementing a special constraint that used the
Container's EClass (e.g. TabFolder), navigated to the type parameter
(e.g. Tab) and used this for checking the type of the children. I think
this technique can be used for other problems, perhaps also specializing
property editing, but I don't think EMF can do this on its own. In my
case, I knew that this specific type parameter limited that specific
reference, but I suspect (but please correct me if I'm wrong) that in
general the analysis that would be required is too complex for EMF to do
it automatically.
Hallvard
|
|
|
| Re: Editing a generic attribute in the property sheet pane [message #520192 is a reply to message #520117] |
Thu, 11 March 2010 14:20 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
An instance of Container's eClass() will simply return the EClass for
Container. There's no information at that point which EClass or
EDataType is bound to T. Certainly there are cases like the one
described in this chain, where someone subclasses Container with a new
EClass and the EGenericSuperTypes do end up specifying the EClass or
EDataType bound to T as part of defining Container to be the super type
where it would be possible to do more. I imagine there are other cases
where the object is known to be referenced by a feature and the type of
the feature helps further specify the bounds. There are likely places in
the code where checking for this type of situation could provide type
information that's otherwise erased, but that's certainly a complication
and an expense. Not only that, but you might well require more context,
the original most derived class of the instance owning the feature, or
the type of the feature referring to the instance, than you actually
have available locally.
Hallvard Trætteberg wrote:
> Ed Merks wrote:
>>
>> Seems reasonable, but keep in mind that EMF like Java defines
>> generics in a way where it's generally erased at runtime.
>
> I've encountered a problem which I think is similar. I had an abstract
> container class with a type parameter limiting its allowed children:
> Container<T extends Component> with a containment reference children
> having T as its eType. Specific containers then could limit their
> children, e.g. TabFolder<Tab>. This works well when you use the
> specific type names like TabFolder in your code, since calls like
> getChildren().add/remove can be checked statically. When you instead
> write generic code against the Container class, nothing prevents you
> from adding other kinds of Components.
>
> I handled this myself by implementing a special constraint that used
> the Container's EClass (e.g. TabFolder), navigated to the type
> parameter (e.g. Tab) and used this for checking the type of the
> children. I think this technique can be used for other problems,
> perhaps also specializing property editing, but I don't think EMF can
> do this on its own. In my case, I knew that this specific type
> parameter limited that specific reference, but I suspect (but please
> correct me if I'm wrong) that in general the analysis that would be
> required is too complex for EMF to do it automatically.
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Editing a generic attribute in the property sheet pane [message #520223 is a reply to message #520192] |
Thu, 11 March 2010 15:25 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Ed,
I think we agree. I just wanted to point out that in specific cases,
like mine, it's possible to use the meta-information (oops, I just said
the m-word) to discover relevant constraints. In general, it may be very
complicated and maybe impossible, and EMF can certainly not do it
automagically.
Hallvard
Ed Merks wrote:
> Hallvard,
>
> An instance of Container's eClass() will simply return the EClass for
> Container. There's no information at that point which EClass or
> EDataType is bound to T. Certainly there are cases like the one
> described in this chain, where someone subclasses Container with a new
> EClass and the EGenericSuperTypes do end up specifying the EClass or
> EDataType bound to T as part of defining Container to be the super type
> where it would be possible to do more. I imagine there are other cases
> where the object is known to be referenced by a feature and the type of
> the feature helps further specify the bounds. There are likely places in
> the code where checking for this type of situation could provide type
> information that's otherwise erased, but that's certainly a complication
> and an expense. Not only that, but you might well require more context,
> the original most derived class of the instance owning the feature, or
> the type of the feature referring to the instance, than you actually
> have available locally.
>
>
> Hallvard Trætteberg wrote:
>> Ed Merks wrote:
>>>
>>> Seems reasonable, but keep in mind that EMF like Java defines
>>> generics in a way where it's generally erased at runtime.
>>
>> I've encountered a problem which I think is similar. I had an abstract
>> container class with a type parameter limiting its allowed children:
>> Container<T extends Component> with a containment reference children
>> having T as its eType. Specific containers then could limit their
>> children, e.g. TabFolder<Tab>. This works well when you use the
>> specific type names like TabFolder in your code, since calls like
>> getChildren().add/remove can be checked statically. When you instead
>> write generic code against the Container class, nothing prevents you
>> from adding other kinds of Components.
>>
>> I handled this myself by implementing a special constraint that used
>> the Container's EClass (e.g. TabFolder), navigated to the type
>> parameter (e.g. Tab) and used this for checking the type of the
>> children. I think this technique can be used for other problems,
>> perhaps also specializing property editing, but I don't think EMF can
>> do this on its own. In my case, I knew that this specific type
>> parameter limited that specific reference, but I suspect (but please
>> correct me if I'm wrong) that in general the analysis that would be
>> required is too complex for EMF to do it automatically.
>>
>> Hallvard
|
|
|
Goto Forum:
Current Time: Fri Sep 20 13:18:36 GMT 2024
Powered by FUDForum. Page generated in 0.04016 seconds |
] 
Search
Help
Register
Login
Home
