> > > 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.
> >
> I don't understand you. My adaption to the code will only trigger those
> observers that need to be singaled. This without any extra cost. Why
> would it be more expensive to invoke the nodeRemoteChanged method of the
> parent builder, than the nodeLocalChanged of the parent builder? Both
> invocations will only trigger some observers that can be added to the
> builder. To make things more clear, I added the self describing source
> code below ;-). Nothing changes untill a signal has reached the
> nodeLocalChanged/nodeRemoteChanged of the appropriate builders (maybe
> over a network). In the nodeChanged methods, the observers to a specific
> builder are signaled, so far nothing new. After signaling the listners
> the partentBuilder will be invoked (the same method only of the
> mediafragment builder instead of the audiofragment builder). This time
> the method will skip the caching stuff, because it's already done, than
> the observers will be signaled. And again the partentBuilder will be
> invoked if available. Is this not exactly the behaviour we want ?
Ok, try it once again, then we better go to IRC :) First your right
about the nodeRemoteChanged does not cost extra, that was a
misjudgment of mine, it will only travel the local machine. Is this the
bahaviour we want? Take the case of the MediaBuilder: My central
point is when an AudioFragment changes and in the situation all
builders listen the signal will travel this way:
AudioFragment.nodeChanged
MediaFragMent.nodeChanged
MMObjectBuilder.nodeChanged
Any observer added with addObserver AudioFragment
MediaFragment.nodeChanged
MMObjectBuilder.nodeChanged
Any observer added witth addObserver MediaFragment
MMObjectBuilder.nodeChanged
Any observer added with addObserver MMObject
In the situation that addXXXObserver would add the observer to all
relavant builders you would get:
AudioFragment.nodeChanged
MediaFragMent.nodeChanged
MMObjectBuilder.nodeChanged
Any observer added with addObserver AudioFragment,MediaFragment or MMobject
I think the last route is significantly shorter.
> public boolean nodeRemoteChanged(String machine,String number,String
> builder,String ctype) {
> if(builder.equals(tableName) {
> // do caching stuff
> }
>
> // signal all the other objects that have shown interest in changes of
> nodes of this builder type.
> for (Enumeration e=remoteObservers.elements();e.hasMoreElements();) {
> MMBaseObserver o=(MMBaseObserver)e.nextElement();
> o.nodeRemoteChanged(machine,number,builder,ctype);
> }
>
> MMObjectBuilder pb = getParentBuilder();
> if(pb!=null) {
> pb.nodeRemoteChanged(machine, number, builder, ctype);
> }
>
>
> > 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.
> >
> This is not true, see the code above that i proposed. It's only invoking
> the nodeChanged of its parentBuilder.
What is not true? A builder does not have to subscribe to changes of its
own nodes, it gets them through nodeXXXChanged without subscription.
Or are you not using addXXXObserver to listen to changes of the
MediaFragment in another builder?
> > 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?
> >
> > 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.
> >
> I think both solutions are not so different:
> In my case you only add an observer to the builder you want to listen
> to. So if you want to listen to mediafragments that change, you only add
> an observer to the mediafragment builder.
> In you case you add observers to the builder you want to listen to, and
> to all the possible child builders. This to avoid that the method in the
> partenBuilders have to be invoked.
>
> One drawback i see in your solution it that the nodeChanged of the
> mediafragment builder itself is not invoked when a node of the
> audioframgent builder changes.
That's a nice point to think about. It does get the signal I say, you say
it doesn't. I finally found out where the differences come from and found
out why you say it doesn't. In my view the AudioFragment builder
gets the signal, it extends the MediaFragment builder, so I say the
MediaFragment builder does get the signal. However only one instance
of the MediaFragment builder will get it. For instance the instance with as
child the VideoFragment builder will not get it. You added your observer
with addLocalObeserver and the current implementation adds your observer
to the MediaFragment builder returned by getMMObject("mediafragments").
This is not the instance whose nodes are changing, so it won't be signaled.
So you say the MediaFragments builder is not signaled and propose to
signal it. But then you signal an instance of the MediaFragments Builder whose
node did not change. The AudioFragment builder as child of the MediaFragment
builder is the MediaFragment builder whos node changed and that is the
MediaFragment builder that needs to be signalled and already recieves
the signal. The problem lies not in the MediaBuilder not recieving the signal,
in my opionion it does get the signal, but in that your observer is not added
to all three instances of the MediaBuilder. (VideoFragment, AudioFragment,
and MediaFragment) if you request to monitor mediafragments.
Wilbert
