Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [Ecore] don't set labelFeature in genModel
| [Ecore] don't set labelFeature in genModel [message #1691790] |
Thu, 09 April 2015 12:06  |
Eclipse User |
|
|
|
Hello,
I have a Model with class Foo, Foo contains an EReference of class Bar, Bar contains two attributs "a" and b, both String. My genmodel automatically sets the labelFeature of Bar to "a". Thus, a Bar instance is automatically labelled as "Bar <a>"
I can see the use of the labelFeature for lists of instances of Bar, where the labelFeature would contain some kind of ID or description of the Bar-instance.
In my case however, I run into a problem. Neither "a" nor "b" are intended to be IDs or descriptions. There is only ever one reference of Bar in Foo, which makes further identification unnecessary. I know it is possible to overwrite getText in a custom item provider for Bar, but my real model contains multiple classes that are only single references in another class. I would have to do this for each of these classes. Another alternative I see would be to add another attribute "id", that would never be shown or filled, so that Bar would always be labelled as "Bar". These don't seem to be good approaches for this.
So I wondered, is there any setting I missed that solves my problem? I'd rather not have any labelFeature set for these classes. Is there any other, better way to do this?
Thanks in advance,
Matthias
|
|
|
| Re: [Ecore] don't set labelFeature in genModel [message #1691831 is a reply to message #1691790] |
Fri, 10 April 2015 00:24  |
| Eclipse User |
|
|
|
Matthias,
Comments below.
On 09/04/2015 6:06 PM, Matthias Juchmes wrote:
> Hello,
>
> I have a Model with class Foo, Foo contains an EReference of class
> Bar, Bar contains two attributs "a" and b, both String. My genmodel
> automatically sets the labelFeature of Bar to "a". Thus, a Bar
> instance is automatically labelled as "Bar <a>"
>
> I can see the use of the labelFeature for lists of instances of Bar,
> where the labelFeature would contain some kind of ID or description of
> the Bar-instance.
Yes, in a tree view, or any type of view, you'll generally want a
non-empty string to identify each instance.
>
> In my case however, I run into a problem. Neither "a" nor "b" are
> intended to be IDs or descriptions.
Of course we can't know the semantics of the model, so some arbitrary
attribute is chosen, with preference given to an attribute named "name"
or "id"...
> There is only ever one reference of Bar in Foo, which makes further
> identification unnecessary. I know it is possible to overwrite getText
> in a custom item provider for Bar, but my real model contains multiple
> classes that are only single references in another class.
It seems their only purpose is the attributes they add to the
information, so I imagine one would want to see those values in the tree
view, but I don't know the semantics of your model either.
> I would have to do this for each of these classes.
Not the end of the world to do so...
> Another alternative I see would be to add another attribute "id", that
> would never be shown or filled, so that Bar would always be labelled
> as "Bar". These don't seem to be good approaches for this.
>
> So I wondered, is there any setting I missed that solves my problem?
No.
> I'd rather not have any labelFeature set for these classes.
It seems very strange to me to have items without a label at all...
> Is there any other, better way to do this?
No, just hand written code...
>
> Thanks in advance,
>
> Matthias
|
|
|
| Re: [Ecore] don't set labelFeature in genModel [message #1692623 is a reply to message #1691831] |
Thu, 16 April 2015 22:30 |
| Eclipse User |
|
|
|
Hello Ed
I too have this problem in my TreeViewer. Some classes are just wrapper
container classes and there we dnt want to show the attributes. I
achieved the same by overriding the getText. But shouldnt there be a way
to say, no labelFeature so that only the Class Name is displayed.
Regards
Malai
On 4/10/2015 9:54 AM, Ed Merks wrote:
> Matthias,
>
> Comments below.
>
> On 09/04/2015 6:06 PM, Matthias Juchmes wrote:
>> Hello,
>>
>> I have a Model with class Foo, Foo contains an EReference of class
>> Bar, Bar contains two attributs "a" and b, both String. My genmodel
>> automatically sets the labelFeature of Bar to "a". Thus, a Bar
>> instance is automatically labelled as "Bar <a>"
>>
>> I can see the use of the labelFeature for lists of instances of Bar,
>> where the labelFeature would contain some kind of ID or description of
>> the Bar-instance.
> Yes, in a tree view, or any type of view, you'll generally want a
> non-empty string to identify each instance.
>>
>> In my case however, I run into a problem. Neither "a" nor "b" are
>> intended to be IDs or descriptions.
> Of course we can't know the semantics of the model, so some arbitrary
> attribute is chosen, with preference given to an attribute named "name"
> or "id"...
>> There is only ever one reference of Bar in Foo, which makes further
>> identification unnecessary. I know it is possible to overwrite getText
>> in a custom item provider for Bar, but my real model contains multiple
>> classes that are only single references in another class.
> It seems their only purpose is the attributes they add to the
> information, so I imagine one would want to see those values in the tree
> view, but I don't know the semantics of your model either.
>> I would have to do this for each of these classes.
> Not the end of the world to do so...
>> Another alternative I see would be to add another attribute "id", that
>> would never be shown or filled, so that Bar would always be labelled
>> as "Bar". These don't seem to be good approaches for this.
>>
>> So I wondered, is there any setting I missed that solves my problem?
> No.
>> I'd rather not have any labelFeature set for these classes.
> It seems very strange to me to have items without a label at all...
>> Is there any other, better way to do this?
> No, just hand written code...
>>
>> Thanks in advance,
>>
>> Matthias
>
|
|
|
Goto Forum:
Current Time: Wed Jul 30 16:09:16 EDT 2025
Powered by FUDForum. Page generated in 0.03266 seconds |
Home