Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 364529

Summary: UIEventPublisher does not handle Notification.ADD_MANY and REMOVE_MANY
Product: [Eclipse Project] Platform Reporter: Brian de Alwis <bsd>
Component: UIAssignee: Brian de Alwis <bsd>
Status: VERIFIED FIXED QA Contact:
Severity: major    
Priority: P3 CC: dean.t.roberts, emoffatt, pwebster, remy.suen
Version: 4.2   
Target Milestone: 4.2.1   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
patch v1 none

Description Brian de Alwis CLA 2011-11-22 19:21:59 EST 
I was walking through some code that sought to respond to changes to the MApplication's menu contributions (formed from the 3.x <menuContributions> stanzas).  My event listener was getting a strange event whose type was "UNKNOWN".

 It turns out that adding the generated MMenuContributions to the app instance (in MenuPersistence#read()) causes an EMF ADD_MANY notification, which we don't interpret properly in UIEventPublisher#getEventType().  We instead map the notification to event type "UNKNOWN", which has the effect that the old and new values are never set in the event properties.

I'm not sure what we should be mapping this ADD_MANY to.
Comment 1 Eric Moffatt CLA 2012-06-08 14:38:58 EDT 
We should also see if we can adjust to handling the EMF 'move' semantic (where you don't do an explicit 'remove' from the current parent, you just do an 'add' to the new one. There is a way to detect that this is the case in the event but I've forgotten what it is...
Comment 2 Paul Webster CLA 2012-06-20 10:52:33 EDT 
Brian, would you be able to look at this in 4.2.1?

PW
Comment 3 Brian de Alwis CLA 2012-06-20 11:03:16 EDT 
Sure
Comment 4 Brian de Alwis CLA 2012-06-25 12:55:35 EDT 
Created attachment 217822 [details]
patch v1

This patch adds support for three new event types to UIEvents.EventTypes (ADD_MANY, REMOVE_MANY, and MOVE) correspond to EMF's notification types.  It also adds a new event property to (UIEvents.EventTags.POSITION) to record where operations took place (primarily for MOVE, but also useful for REMOVE and REMOVE_MANY).

Unlike ADD and REMOVE, ADD_MANY and REMOVE_MANY report collections of the added/removed objects.  In changing existing code to handle both ADD/ADD_MANY and REMOVE/REMOVE_MANY, I ended up adding two helper functions to UIEvents:

  * contains(Event e, String propName, Object o): check if a property contained a particular value (e.g., in MinMaxAddon: to check if new tags contains "Minimized" on ADD_MANY)

  * asIterable(Event e, String propName): return an iterator over the property regardless of whether a single instance or a collection (e.g., for PartRenderingEngine to iterate over multiple elements in an ADD_MANY)

I haven't adapted any code to make use of MOVE -- that should be done separately, IMHO.
Comment 5 Brian de Alwis CLA 2012-07-04 15:07:43 EDT 
Fix committed to master (24bfc76ae59a0a8b47f7fde56797921723f6f994)
Comment 6 Brian de Alwis CLA 2012-08-28 10:11:45 EDT 
*** Bug 317419 has been marked as a duplicate of this bug. ***
Comment 7 Brian de Alwis CLA 2012-08-30 14:50:36 EDT 
Verified in M20120829-1200