Rob Vermeulen wrote > Wilbert Wrote: > > That's not the way to implement it. Your override of nodeLocalChanged and > > nodeRemoteChanged should call super.nodeLocalChanged and > > super.nodeRemoteChanged to signal your parent. The parent should > > call its super if it places an override, so in the end MMObjectBuilders > > nodeLocalChanged and nodeRemoteChanged is called. If you don't > > call super then the Node cache of MMBase handled by MMObjectBuilder > > nodeLocalChanged and nodeRemoteChanged will not operate as > > intended. > > > My idea is not to override the changeLocalNode and changeRemoteNode > methods in MMObjectBuilder. I just want to put an extra statement in > those methods that will invoke the changeLocalNode/changeRemoteNode of > the partentBuilder (if available). Thought your problem was you did not get the changed signal in the MediaFragments builder when an AudioFragment changed, so you want to add this new code. My objection is that you already should get the signal without the adding of your new code. If you have an AudioFragment builder extending the MediaFragment builder then the current code calls AudioFragmnet.nodeXXXchanged. Without adding of your new code this already should pass through the MediaFragment builder. Two possible routes: If the AudioPart builder overrides the changed methods then it is responsible for calling the MediaFragment nodeChanged methods. If the AudioFragment builder does not overide it, then the current code calls the inherited method of the MediaFragments base class, either way, in the current setup without the adding of the new code, the MediaBuilder should already recieve the signal. If it does not something else might be wrong?
regards, Wilbert.
