Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: [ FEATURE REQUEST] observers cast to Observer instead of IObserver  (Read 17387 times)
gordogre
Newbie
*
Posts: 1


View Profile Email
« on: September 06, 2008, 02:02:55 »

Unless I am missing something, I should be able to implement the IObserver interface in my own code, and use my own classes in View.registerObserver / View.removeObserver, and in my simple case, my implementing class uses itself as the notifyContext.

However, even though View.registerObserver takes a param of type IObserver, the implentation in View.removeObserver casts the elements of the associated 'observers' array to Observer instead of IObserver, which in my case yields a class cast exception:

line 145 of View.as:

:
if ( Observer(observers[i]).compareNotifyContext( notifyContext ) == true ) {

I am assuming this is an oversight - or is there some reason I should not be implementing IObserver in my own classes?

Thanks - unlike most of the Flex API, it's almost a pleasure to find a bug in PMVC as it's such a rare occurance  ;)

Greg
« Last Edit: April 03, 2009, 10:31:16 by puremvc » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: September 06, 2008, 02:39:18 »

Greg,

The reason registerObserver and removeObserver are not included on the IFacade interface is because they're not expected to be used except internally by the by the View itself. If you are retrieving the View and calling these methods you are 'pioneering'; modifying the lists in a fashion that falls outside the normal practices. That doesn't mean it won't work and you shouldn't be able to do it.  Extensibility of the framework in this way was part of the value proposition from the start.

Workaround: Check out PureMVC source, make the change (change 'Observer' to 'IObserver'), and build based on that project.

-=Cliff>
« Last Edit: April 03, 2009, 10:32:25 by puremvc » Logged
enzuguri
Newbie
*
Posts: 1


View Profile Email
« Reply #2 on: April 03, 2009, 02:31:42 »

Bump Bump,

Can we try and get this change as quickly as possible, it literally involves putting the letter I in front of the aforementioned code (I have checked out the source made a SWC myself, however I would rather it be official)

I have some cooling PureMVC style binding and other observer implementations going on that require this change.

Many thanks
« Last Edit: April 03, 2009, 10:32:33 by puremvc » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: April 03, 2009, 07:22:53 »

I've held off on this because:

A) The Observer class is not meant to be used really by the user-subclassed framework classes; there is no intended or known use case for it.

and

B) If you are monkeying with it you are most likely to end up having problems, which (because of A), I'm not prepared to support. Trust me, at least 80% of the actual bugs reported/fixed have been directly related to Observer list management.

While it may seem like simply adding a letter, (using IObserver as opposed to Observer in one place), the implications to any framework modifications are far broader.

This is the reference implementation and 10 other ports have to follow this one in addition to MultiCore and all implementations of it. Therefore it needs to be an actual bug, and that means something in the framework functionality does not work properly as advertised.

Interfaces have been supplied and used for those classes that are intended to be replaceable with user implementations. Observer is definitely not one of those classes. The framework is intended to be very extensable, but where it comes to Observer notification there are "No User Servicable Parts Inside".

Can you describe what it is that you are doing with it?

-=Cliff>
« Last Edit: April 03, 2009, 10:32:42 by puremvc » Logged
ChSemrau
Newbie
*
Posts: 5


View Profile Email
« Reply #4 on: February 15, 2011, 03:24:21 »

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
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: February 17, 2011, 09:37:59 »

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.

Why can't you remove the IObserver?

-=Cliff>
Logged
ChSemrau
Newbie
*
Posts: 5


View Profile Email
« Reply #6 on: February 17, 2011, 01:33:15 »

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
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: February 20, 2011, 01:22:29 »

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.)

If you're just logging note traffic, aside from using PureMVC Console, you could just override your facade's notifyObserver class to do the logging. Why do you need a custom Observer class?

If you really want custom observers, you can simply extend View and Controller, make your View class use your Observer class, and modify Controller.initializeController method to get the reference to your View instance. In the Facade, override initializeView and initializeController to use your View and Controller.

-=Cliff>
Logged
ChSemrau
Newbie
*
Posts: 5


View Profile Email
« Reply #8 on: February 22, 2011, 04:18:50 »

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
Logged
ChSemrau
Newbie
*
Posts: 5


View Profile Email
« Reply #9 on: August 09, 2011, 08:19:51 »

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.
Logged
Pages: [1]
Print