Eclipse Community Forums: EMF » Intended behaviour of ItemPropertyDescriptorDecorator

Help

Home

Home » Modeling » EMF » Intended behaviour of ItemPropertyDescriptorDecorator(EMF edit)

Show: Today's Messages :: Show Polls :: Message Navigator

Intended behaviour of ItemPropertyDescriptorDecorator [message #1693371]

Thu, 23 April 2015 15:08

Erlend Stav

Messages: 12
Registered: September 2012

Junior Member

What is the intended behaviour of the ItemPropertyDescriptorDecorator?

From the EMF book example and other references I have seen, my expectation was that this class was a convenience class that by default forwards all the calls to the IItemPropertyDescriptor provided in the constructor, and that it would be useful when you just want to override a couple of methods from the interfaces.

However, the implementation of almost the methods ignores the thisObject parameter, and instead uses the object that you set in the constructor when it forwards the call to the original IItemPropertyDescriptor.

From the documentation of the class, it is not possible to see if this is an intended feature or whether it is a systematic bug in most of the methods. The effect when using the decorator class in customisation of item providers (like shown in the EMF book) is that unless you change the default generated getPropertyDescriptors class to always generate new itemPropertyDescriptors, the property editor will only work correctly for the first object you select of the type you have decorated.

Report message to a moderator

Re: Intended behaviour of ItemPropertyDescriptorDecorator [message #1693486 is a reply to message #1693371]

Fri, 24 April 2015 13:49

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Erland

Comments below.

On 23.04.2015 17:08, Erlend Stav wrote:
> What is the intended behaviour of the ItemPropertyDescriptorDecorator?
>
> From the EMF book example and other references I have seen, my
> expectation was that this class was a convenience class that by default
> forwards all the calls to the IItemPropertyDescriptor provided in the
> constructor, and that it would be useful when you just want to override
> a couple of methods from the interfaces.

No, it's generally easiest to override the implementation that's
otherwise being used. I.e., to specialize a property descriptor one
generally create a derived implementation in the item provider method
where the property descriptor is created.

>
> However, the implementation of almost the methods ignores the thisObject
> parameter, and instead uses the object that you set in the constructor
> when it forwards the call to the original IItemPropertyDescriptor.
>
> From the documentation of the class, it is not possible to see if this
> is an intended feature or whether it is a systematic bug in most of the
> methods.
A feature.
> The effect when using the decorator class in customisation of
> item providers (like shown in the EMF book) is that unless you change
> the default generated getPropertyDescriptors class to always generate
> new itemPropertyDescriptors, the property editor will only work
> correctly for the first object you select of the type you have decorated.
Unless you make the item providers stateful so a new one is created for
each instance.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator