Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF Parsley » Use getDisplayName() of PropertyDescriptors to get display names of features
Use getDisplayName() of PropertyDescriptors to get display names of features [message #1701546] Tue, 14 July 2015 06:04 Go to next message
Stephan Hildebrandt is currently offline Stephan HildebrandtFriend
Messages: 25
Registered: July 2015
Junior Member
Hi,

if no label providers are specified, Parsley uses the ItemLabelProvider in the *.edit-plugin to resolve the display names of classes. However, it does not use the property descriptors to resolve the display names of features. Instead, the feature name itself is displayed. Is there a specific reason for this behavior? How can I implement a FeatureCaptionProvider that delegates to the appropriate property descriptor of the feature? The problem I'm currently facing is that the ItemProviderAdapterFactory needs an instance of the class to which the feature belongs in order to return the property descriptor. However, the method defaultText() of FeatureCaptionProvider only gets the EStructuralFeature itself. Creating a dummy instance of the class would be a possibility but that does not work for concrete classes. Is there another way to get the instance EObject, e.g. via DI?


Best regards,

Stephan
Re: Use getDisplayName() of PropertyDescriptors to get display names of features [message #1701699 is a reply to message #1701546] Wed, 15 July 2015 06:36 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1750
Registered: July 2009
Location: Firenze, Italy
Senior Member
On 14/07/2015 15:04, Stephan Hildebrandt wrote:
> Hi,
>

Hi Stephan

see comments below

> if no label providers are specified, Parsley uses the ItemLabelProvider
> in the *.edit-plugin to resolve the display names of classes. However,
> it does not use the property descriptors to resolve the display names of
> features. Instead, the feature name itself is displayed. Is there a
> specific reason for this behavior? How can I implement a

I guess this can be considered a bug; could you please file a bug?

> FeatureCaptionProvider that delegates to the appropriate property
> descriptor of the feature? The problem I'm currently facing is that the
> ItemProviderAdapterFactory needs an instance of the class to which the
> feature belongs in order to return the property descriptor. However, the
> method defaultText() of FeatureCaptionProvider only gets the
> EStructuralFeature itself. Creating a dummy instance of the class would
> be a possibility but that does not work for concrete classes. Is there
> another way to get the instance EObject, e.g. via DI?

If you have an EStructuralFeature you can use getEContainingClass,
http://download.eclipse.org/modeling/emf/emf/javadoc/2.11/org/eclipse/emf/ecore/EStructuralFeature.html#getEContainingClass(),
to retrieve its class.

Does that temporarily fix your problem?

cheers
Lorenzo

>
>
> Best regards,
>
> Stephan


--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
Re: Use getDisplayName() of PropertyDescriptors to get display names of features [message #1701702 is a reply to message #1701699] Wed, 15 July 2015 06:54 Go to previous messageGo to next message
Stephan Hildebrandt is currently offline Stephan HildebrandtFriend
Messages: 25
Registered: July 2015
Junior Member
Hi Lorenzo,

I'll file a bug.

No, that does not solve the problem. The problem is not getting the EClass that contains the feature. The problem is getting the instance whose properties are displayed in the end. The method defaultText() only gets the feature but the property descriptor needs the instance as well.


Best regards,

Stephan
Re: Use getDisplayName() of PropertyDescriptors to get display names of features [message #1701703 is a reply to message #1701702] Wed, 15 July 2015 07:06 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1750
Registered: July 2009
Location: Firenze, Italy
Senior Member
On 15/07/2015 08:54, Stephan Hildebrandt wrote:
> Hi Lorenzo,
>
> I'll file a bug.
>
> No, that does not solve the problem. The problem is not getting the
> EClass that contains the feature. The problem is getting the instance
> whose properties are displayed in the end. The method defaultText() only
> gets the feature but the property descriptor needs the instance as well.
>

Hi

If ItemProviderAdapterFactory needs an instance (EObject) then I
remember why we don't delegate to it by default: the
FeatureCaptionProvider is used also in contexts where there's no
instance yet, e.g., for the headers of the columns of the table. In the
form, instead, the EObject is actually available (I guess this is your
context, isn't it?). So we can think of enriching the API so that when
an EObject is available then we delegate to ItemProviderAdapterFactory,
and, in general, the EObject is passed to defaultText as well.

what do you think?
cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
Re: Use getDisplayName() of PropertyDescriptors to get display names of features [message #1701704 is a reply to message #1701703] Wed, 15 July 2015 07:16 Go to previous messageGo to next message
Stephan Hildebrandt is currently offline Stephan HildebrandtFriend
Messages: 25
Registered: July 2015
Junior Member
Hi Lorenzo,

> Hi
>
> If ItemProviderAdapterFactory needs an instance (EObject) then I
> remember why we don't delegate to it by default: the
> FeatureCaptionProvider is used also in contexts where there's no
> instance yet, e.g., for the headers of the columns of the table. In the
> form, instead, the EObject is actually available (I guess this is your
> context, isn't it?).

Yes, exactly. I think, this is the common case.

> So we can think of enriching the API so that when
> an EObject is available then we delegate to ItemProviderAdapterFactory,
> and, in general, the EObject is passed to defaultText as well.
>
> what do you think?
> cheers
> Lorenzo

That sounds good.


Best regards,

Stephan
Re: Use getDisplayName() of PropertyDescriptors to get display names of features [message #1701714 is a reply to message #1701704] Wed, 15 July 2015 08:19 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1750
Registered: July 2009
Location: Firenze, Italy
Senior Member
On 15/07/2015 09:16, Stephan Hildebrandt wrote:
> Hi Lorenzo,
>
>> Hi
>>
>> If ItemProviderAdapterFactory needs an instance (EObject) then I
>> remember why we don't delegate to it by default: the
>> FeatureCaptionProvider is used also in contexts where there's no
>> instance yet, e.g., for the headers of the columns of the table. In the
>> form, instead, the EObject is actually available (I guess this is your
>> context, isn't it?).
>
> Yes, exactly. I think, this is the common case.
>
>> So we can think of enriching the API so that when
>> an EObject is available then we delegate to ItemProviderAdapterFactory,
>> and, in general, the EObject is passed to defaultText as well.
>>
>> what do you think?
>> cheers
>> Lorenzo
>
> That sounds good.

Hi Stephan

In the meantime I had a look at the library example edit plugin, and I
see that getPropertyDescriptors(Object object) takes an Object, but then
it does not use it all. To be honest I think it makes sense NOT to use
the instance to build descriptions of features, since such descriptions
usually do not depend on the properties of the object itself... even if
you want to build a property description based on some state of the
object, as soon as you modify the object you should also modify its
property description, which I think is not considered at all in EMF.

Is using the object itself a requirement in your case, or do you need it
only to use the ItemProviderAdapterFactory? If you don't need the state
of the object and you simply want to use the edit plugin I think you can
simply pass null. Could you please try that? I'm assuming you already
have access to the ItemProviderAdapterFactory.

In the meantime we'll work on using it also on Parsley as a default
case, possibly considering also the case when an EObject is effectively
available.

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
Re: Use getDisplayName() of PropertyDescriptors to get display names of features [message #1701740 is a reply to message #1701714] Wed, 15 July 2015 10:33 Go to previous messageGo to next message
Stephan Hildebrandt is currently offline Stephan HildebrandtFriend
Messages: 25
Registered: July 2015
Junior Member
Hi Lorenzo,

I need the instance to get the property descriptor from the ItemProviderAdapterFactory like this

((IItemPropertySource) adapterFactory.adapt(instance, IItemPropertySource.class).getPropertyDescriptor(instance, feature)

You are right that getPropertyDescriptor does not use the instance parameter in most cases but it is required in order to get the IItemPropertySource. I don't know of any other way to get the property descriptors. Usually, you only have the AdapterFactory available in an editor.


Best regards,

Stephan
Re: Use getDisplayName() of PropertyDescriptors to get display names of features [message #1701744 is a reply to message #1701740] Wed, 15 July 2015 10:58 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1750
Registered: July 2009
Location: Firenze, Italy
Senior Member
On 15/07/2015 12:33, Stephan Hildebrandt wrote:
> Hi Lorenzo,
>
> I need the instance to get the property descriptor from the
> ItemProviderAdapterFactory like this
>
> ((IItemPropertySource) adapterFactory.adapt(instance,
> IItemPropertySource.class).getPropertyDescriptor(instance, feature)
>
> You are right that getPropertyDescriptor does not use the instance
> parameter in most cases but it is required in order to get the
> IItemPropertySource. I don't know of any other way to get the property
> descriptors. Usually, you only have the AdapterFactory available in an
> editor.

OK, I see.

By the way, you also tried creating an instance with the EClass and it
did not work?

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
Re: Use getDisplayName() of PropertyDescriptors to get display names of features [message #1701747 is a reply to message #1701744] Wed, 15 July 2015 11:10 Go to previous messageGo to next message
Stephan Hildebrandt is currently offline Stephan HildebrandtFriend
Messages: 25
Registered: July 2015
Junior Member
Yes, I did. But that does not work for abstract classes. For abstract classes, I would need to search for a concrete subclass and instantiate it. But that is not that simple (and it does not seem to be elegant) because an EClass has only references to its superclasses, not its subclasses. I would need to examine all classes in the package and search for a subclass of the abstract class. However, subclasses may be (and in my case, are) spread among several packages. In fact, in my case, the abstract base classes are contained in a separate package that does not contain any concrete classes. So the search space becomes very large and the whole approach infeasible.


Best regards,

Stephan
Re: Use getDisplayName() of PropertyDescriptors to get display names of features [message #1708617 is a reply to message #1701747] Fri, 18 September 2015 06:52 Go to previous message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1750
Registered: July 2009
Location: Firenze, Italy
Senior Member
On 15/07/2015 13:10, Stephan Hildebrandt wrote:
> Yes, I did. But that does not work for abstract classes. For abstract
> classes, I would need to search for a concrete subclass and instantiate
> it. But that is not that simple (and it does not seem to be elegant)
> because an EClass has only references to its superclasses, not its
> subclasses. I would need to examine all classes in the package and
> search for a subclass of the abstract class. However, subclasses may be
> (and in my case, are) spread among several packages. In fact, in my
> case, the abstract base classes are contained in a separate package that
> does not contain any concrete classes. So the search space becomes very
> large and the whole approach infeasible.
>
>
> Best regards,
>
> Stephan

Hi

the problem is fixed in the new release 0.5.0 which is already
available, please have a look at the updated documentation (and
migration guide).

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
Previous Topic:Context menu in SelectionTreeView
Next Topic:TreeTable
Goto Forum:
  


Current Time: Sat May 26 14:09:24 GMT 2018

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

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

Back to the top