Re: Changes to Events API

Hi,
I would like to implement the feature I posted to this mailing list some 
time ago (see below). I wanted to solve it the way suggested by Holger - 
i.e. by reserving a flag in the bitmask. However I have the following 
problem with the approach and I hope to get some feedback on it:
Once the event object is created, it is not acceptable to change its ID. 
However in this case the event object should either have a different ID 
depending on whether it is fired on its source or fired on its 
composites, or the filtering mechanism would need to be a bit more 
complicated and the bitmask would no longer be just a mask for event 
IDs. I don't like this and thus instead of using bitmask I would like to 
propose to create one of the following:
1) a separate interface for listener (say MDRComponentChangeListener 
extends MDRChangeListener) - when a listener implements this interface, 
it always receives events also from components.
2) a separate interface for event source (MDRInstanceChangeSource) 
implemented by InstanceHandler and containing two additional addListener 
methods with an additional boolean parameter indicating whether the 
listener should be hierarchical.
3) the same as 2) however the added parameter would be a bitmask for 
component events (if set to 0, listener would get no events from 
components, if set to non-zero value, it would get only the events that 
are "contained" in the bitmask)
4) any other idea?

I guess my preference is #3.
Your feedback is very welcome.
Martin

Martin Matula wrote:
> Hi,
> from the discussions that I saw at some external mailing lists and from 
> the discussions I had with the people here at Sun that intend to use the 
>  MDR it showed up that what would be a good thing to have is a 
> possibility to listen to events on objects' containers (composites). 
> This means that the events should be propagated not only up to the 
> proxies, but also to objects' composites. This way someone who wants to 
> listen to any changes in a Java class would listen to the class only 
> (and would not be forced to register listeners to all the methods, their 
> parameters, attributes, etc.) The same is applicable in many other cases 
> (UML metamodel, XML, etc.)
> Thus I propose that events on RefObjects are propagated also to their 
> composites. Once the event gets to the composite, it will be propagated 
> to its composite, but not to its proxies (thus the current event path 
> via proxies would be followed only for events originating from the given 
> RefObject). I.e.:
> 
> APackage extent contains AClass and BClass class proxies, A is instance 
> for AClass, B is instance for BClass.
> A is a component of B, A is changed -> event goes to A, from A to AClass 
> and B, at B it is forgoten, from AClass it goes to APackage, from 
> APackage it goes to repository.
> 
> Now the question is, how the listeners should register for the events 
> from containers. I would like to add method addListener(..., boolean 
> includeComponents), however this would be applicable only for 
> registering listeners on RefObjects. Should there be a special 
> RefObjectEventSource for RefObjects? Any suggestions are welcome.
> Martin
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]