As far as model change eventing goes I'm of the opinion that first and foremost there should be a single location through which -all- change events funnel for a given domain (i.e. any changes to the domain element or any of its children get reported through a single eventing hub). This allows the implementation of the pattern that Ed mentions, allowing 'filtered' event registration even down to the property level if necessary), while also preserving the ability for the UI to manage the events at a higher level without exploding the listener set.
For UI work I like to have a single listener per GUI element 'type'. For example a -single- listener can manage the menu's on screen display for -all- menu items, a single Table listener can manage all multi-column table etc. The trick when hooking in to the 'global' listener list is to ensure that you can quickly determine which events the listener is -not- interested in (picture a fire hose...;-)...this is the eventing equivalent to graphics clipping. As it turns out this is very simple in practice. The general pattern for a property change is: Am I showing this element? For a simple object this is 'changedElement == myElement', for a List it'd be 'changedElement.getParent() == myElement' and for a Tree structure you should use a Map to determine whether it's visible (found that out during my first implementation of this strategy...;-). Is the particular property one that I have to take action on? For a tree/list/menu item/ctabitem this might just mean that only changes in the Label or Image properties are interesting, for a table it can be checked against the list of properties being displayed in that particular table's columns. Note that this is equivalent (or better) in performance than having an event filtering arrangement which ultimately has to perform the same tests (is this the element/property the listener is registered for?). The advantage here is that the listener structure is -static-; it doesn't change if you use a different element in the table. Imagine a Master/Detail UI (where a selection in one area determines the 'root' of the detail table). Here, having to register discreet event listeners even at the element level can place a high cost on switching between elements (there could be 1000's of detail records) but using this pattern it is -zero- cost... Now if only I can convince people...;-), Eric
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
