>
>
> > 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 ?
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.
> 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.
greetings Rob
