Finally I found the time to work on this topic.

I wrote a new base View class, that overrides registerMediator and removeObserver. The method registerMediator invokes a new method createObserver(mediator:IMediator):IObserver which allows a subclass to provide a different Observer implementation. And as suggested in this topic, the method removeObserver only casts to IObserver. My original subclass now inherits from the new base View instead of the provided View class, and overrides createObserver to provide a logging Observer implementation, which is just what I wanted. Now I see which Mediator gets invoked for which notification.

To log Command invocations, it was enough to override executeCommand of the Controller class.

I wanted to see which notifications are sent and which mediators are notified and which commands are executed. Basically what PureMVC Console does. As written above, wrapping a standard Observer does not help, because I cannot remove the wrapper which is not a subclass of Observer (which is the original topic of this thread!), and I cannot access the observer's notification context, and for a note mapped to a command I would not see the command. So for me, the feature originally requested by Greg, namely that the View class should not cast its IObserver to Observer, is not required.

If and when I find the time to try it again, then as you suggested, I will override several more core actor methods to provide the information I'm interested in.

Christian

Because, as Greg noted in the start of this thread, "the implementation in View.removeObserver casts the elements of the associated 'observers' array to Observer instead of IObserver". This fails, because the forwarding IObserver I wrote is my own implementation of the IObserver interface.

Regards,
Christian

Extend the View class, override the methods you want to change and in your ApplicationFacade, override the initializeView method and instantiate your own View sublcass

Just wanted to note that this is not sufficient. In the current implementation, the Facade invokes initializeModel, initializeController and initializeView in that order. The Controller calls View.getInstance(), before the Facade calls the overridden initializeView, and so the Controller gets the wrong View class.

A possible workaround is to also subclass Controller, override its initializeController method, and in the ApplicationFacade, override initializeController to instantiate the subclassed Controller.


I subclassed all three core actors, and overrode their register methods so that I get an Error if any Proxy, Mediator or Command is registered for a name that is already taken. This way, I get notified during testing when someone "unwittingly un-registers a command". I even produce a stack trace of the first registration and supply it in the Error message upon the second registration attempt, so I can easily jump to both source lines. Also, recently, I overrode the retrieve methods, so I get notified about not-yet-registered proxies (happens more than once during development), instead of having to interpret the inevitable null-Error.

Regards,
Christian

Hello Cliff,

I stumbled across this issue today in the Multicore version, as it still exists in both.

My plan was to trace notifications sent and delivered, primarily out of curiousity, and secondary to help me spot a messaging related bug in my program easier. (I have read about PureMVC Console, but didn't try it yet.)

I tried this by subclassing some core classes, including View. In View.registerObserver, I wrap the given IObserver into my own IObserver implementation that would forward all calls to the original IObserver and additionally trace calls to notifyObserver. But with that changes, I cannot remove an observer. I also noticed that with this approach I cannot access the notification context required for a useful message, but at least I am able to trace notifications being sent and count notifications being observed, and work my way from there to my own bug.

So, like Greg, I did not intend to use or extend the Observer class, but instead provide my own implementation of the IObserver interface.

Regarding the bug criterion that "something in the framework functionality does not work properly as advertised", one responsibility of the View (as stated in the ASDoc) is "Providing a method for attaching IObservers to an INotification's observer list."

Regards,
Christian