Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Intended behaviour of ItemPropertyDescriptorDecorator(EMF edit)
Intended behaviour of ItemPropertyDescriptorDecorator [message #1693371] Thu, 23 April 2015 15:08 Go to next message
Erlend Stav is currently offline Erlend StavFriend
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.
Re: Intended behaviour of ItemPropertyDescriptorDecorator [message #1693486 is a reply to message #1693371] Fri, 24 April 2015 13:49 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30372
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.
Re: Intended behaviour of ItemPropertyDescriptorDecorator [message #1693508 is a reply to message #1693486] Fri, 24 April 2015 15:32 Go to previous message
Erlend Stav is currently offline Erlend StavFriend
Messages: 12
Registered: September 2012
Junior Member
Thanks for your quick and good reply, Ed - it is indeed a simpler and better solution!
Previous Topic:[CDO] Oomph install of CDO sources fails [SOLVED]
Next Topic:[GWT] EMF and GWT JsInterop (2.8, 3.0)
Goto Forum:
  


Current Time: Sun Aug 25 15:23:39 GMT 2019

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

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

Back to the top