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: when we need observer?  (Read 7744 times)
marks416
Sr. Member
****
Posts: 52


View Profile Email
« on: October 05, 2008, 09:09:58 »

I am new to pureMVC

I want to know in which case we need import the observer class.    
org.puremvc.as3.patterns.observer

Thanks

Mark
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: October 06, 2008, 06:25:57 »

Never. It is used internally by the framework and is not something you really ever need to use or import.

-=Cliff>
Logged
guyinthechair
Newbie
*
Posts: 2


View Profile Email
« Reply #2 on: October 08, 2008, 10:46:42 »

Hey Cliff, allow me to share a story from when I used the Observer class directly.

At my last job, I was responsible for porting our very poorly architected Flex app to something more manageable. Almost everything was ported to PureMVC without a hitch, and it took about 8 weeks what had originally taken 10 months to write. However, there was a big part of the app that consisted of "Widgets."

Widgets were dynamically created view modules that displayed and refreshed information (similar to an RSS feed). Widgets had some fairly complex user interactions (custom mouse gestures, etc.), and had taken the original programmer hundreds of hours to write in the old code base. I decided to tackle this problem last because I knew Widgets were complicated and would take the most time of any individual piece. After assessing the situation, I estimated it would take at least a month (maybe more) to refactor this giant mess into the PureMVC architecture, even if we made it easier by using dynamic mediators for each Widget. Needless to say, this was unacceptable to management (why would a single piece make the refactoring take 50% longer?)

However, we still needed Widgets to be able to respond to notifications, so here's the hack-ish and very non-standard way I came up with: inside each Widget, I added a "listNotificationInterests" function and a "handleNotifications" function. When each Widget was created, I looped through each widget's listNotificationInterests function, and registered a new Observer with the View singleton for each notification listed. Something like this:
:
private function registerWidgetObservers(widget:Widget):void
{
var interestsArray:Array = widget.listNotificationInterests();
for(var i:int = 0; i < interestsArray.length; i++)
{
View.getInstance().registerObserver(interestsArray[i], new Observer(widget.handleNotifications, widget));
}
}
This allowed the Widgets to listen to notifications and act accordingly.

I realize this idea is way outside the normal uses of the framework, and made sure that the PM knew that it was a big hack to get these things to work (and that I didn't actually refactor Widgets to be real PureMVC team members). I was between a rock and a hard place, and this was the quickest solution. I guess you make the framework work for you sometimes.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: October 09, 2008, 07:03:22 »

It would be tough to list all possible uses of a hammer.

Observer is sort of like a hammer. Its in the toolbox. Ther framework uses it in a clearly defined way. It just so happens there are no other *intended* uses for it. That doesn't mean you can't find one. And it doesn't even have to be for use with the View. It is simply be a way of passing a callback with context to another collaborator.

-=Cliff>
Logged
Pages: [1]
Print