Home » Modeling » EMF Parsley » Use getDisplayName() of PropertyDescriptors to get display names of features
|
| 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   |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| |
| 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 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| 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 |
 Stephan Hildebrandt
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 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| |
| 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 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| |
| 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 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
Goto Forum:
Current Time: Thu Dec 07 11:36:05 GMT 2023
Powered by FUDForum. Page generated in 0.02293 seconds |
] 
Search
Help
Register
Login
Home
