Rob Vermeulen wrote: > Wilbert wrote: > > Now I see your problem. If you look at the code of MMBase.addLocalObserver > > then you are added to the observer vector of the MediaFragments > > Builder, but not > > to the vector of the VideoFragment en AudioFragment builders. > > > hehe It took some emails, i will try to be more clear next time ;-) :)
> > That's clear, but you agree that this second call to the parent > > builder will > > finally end up for the second time in MMObjectBuilder.nodeXXXChanged > > with only a different builder param? Idem voor de MediaFragments builder > > it will see the changed signal twice or more. Is it very difficult to let > > addXXXObserver add the observer to all relevant builders, so one signal > > can do the job? > > > I see two problems with this. > 1) A MMObjectBuilder only knows when it is having a parentBuilder, so > the childBuilders are not know. But this, probably, has to change in the > future to avoid e.g. that a builder can be deactivated or deleted while > it is having child's. The cost would be to once loop through all builders in the addXXXObserver method and test whether they are instanceof the requested builder, but you'll save the multiple signal, escpacially nodeRemoteChanged is quite an expensive one, for every node that changes in the cloud. > 2) If an audiofragment changes the signal should also go to the > mediafragment builder. Regardless if observers are set! The > mediafragment builder only sends the signals to it's observers and will > ignore the statements for caching, because the cache is already cleared > in the audiofragment builder. That is the current situation, a builder does not have to subscribe with addXXXObserver to recieve changes when one of it's nodes change. Your situation is, if I understand it correctly, that you subscribe to changes of MediaFragments in another builder then the MediaFragments builder, so you do have to subscribe with calling addXXXObserver. If addXXXObserver would honour your request by adding your observer to the AudioFragments, VideoFragments and MediaFragments, then your observer would be notified of changes and we only need one signal to say that a node has changed. If we do it as you propose then the number of signals for a standard builder descending from MMObjectBuilder would double and the number of signals for an AudioFragment would tripple? > b.t.w. It's is not true that some instance would retrieve the node > changes twice. The MMObjectBuilder of audiofragments would receive the > signal (where buildername=audiofragments) and the MMObjectBuild of > mediafragments would receive the signal (where > buildername=audiofragments). In the current implementation the > MMobjectBuilder is responsible to sent signals to all instances that are > listening. Signalling both the AudioFragment as the MediaFragment builder is signaling twice, to a different instance, as much as when you only signal to the AudioFragment builder, descending from the MediaFragment builder. That is the instance whose node has changed, so that is the one to be signaled. If your observer is added to the AudioFragment observer vector too, by addXXXObserver, being an instanceof the MediaFragment builder, then your observer would be signalled properly without the need to send an additional signal. Wilbert.
