It's an AS3 question, I'm having some problems in casting back to Vector, help please

Inside Proxy:
var leaderboardRowVOs:Vector.<LeaderboardRowVO> = new Vector.<LeaderboardRowVO>();
//populate routine
this.facade.sendNotification(ApplicationFacade.LEADERBOARD_SUCCESS, leaderboardRowVOs);

Inside Mediator
      override public function handleNotification(notification:INotification):void {
         switch(notification.getName()) {
            case ApplicationFacade.LEADERBOARD_SUCCESS:
               leaderboard.populate(notification.getBody() as Vector.<LeaderboardRowVO>);
               break;
         }
      }

Inside Component:

public function populate(leaderboardRowVOs:Vector.<LeaderboardRowVO>):void {
         trace(leaderboardRowVOs.length);
}

thanks...

Should be
  if (isset($this->observerMap[ $notification->getName() ]) && $this->observerMap[ $notification->getName() ] != null)
    ... 
  }

instead of
  if ($this->observerMap[ $notification->getName() ] != null) { //causes Notice: Undefined index:  (appearing if you send a notification inside a command)
    ...
  }

just like the way it's coded for registerObservers.

public function registerObserver( $notificationName, IObserver $observer ) {
  if (isset($this->observerMap[ $notificationName ]) && $this->observerMap[ $notificationName ] != null) {
    array_push( $this->observerMap[ $notificationName ], $observer );
  } else {
    $this->observerMap[ $notificationName ] = array( $observer );
  }
}

Further to the approach mentioned in here:
http://pixelmelon.com/index.php?option=com_content&view=article&id=8:swfaddress-with-puremvc-single-core&catid=8&Itemid=25&showall=1&limitstart=

I'm trying to figure out the right approach.

1) As per the above article-> MenuComponent dispatch events, handled by MenuMediator which in turns sends a Notification handled by a UriAddressCommand, UriAddressCommand then retrieves the UriAddressProxy, call function to performs uri operations for browser which then sends a Notification handled by ViewMediators to display the related view.

2) In my approach, I'm not using Command, MenuMediator directly retrieves the UriAddressProxy, call function to perform uri operations for browser and which then sends a Notification handled by ViewMediators to display the related view.

It's the shortest way to go but I'm not sure if it's the right way to do. Please advise.

Thanks, the latest build solved the problem as well.

Any example please.

puremvc.declare("com.Test", { a: 4 });

//use
alert(com.Test.a);

please highlight on the scope param.

Thanks Cliff - Your answer is all in one...

Your answer further refined my question into two categories, client-side caching and server-side caching, thanks for your insight on client-side caching, I'm gonna use it for my applications for iPhone or Flash or JavaScript and save round-trips to server.

I've been trying different things for server-side caching and worked out a solution and I'm glad to see similarities with your answer. I'm posting my solution for guys who would be interested in PureMVC-PHP (Server-side) based caching and for Cliff for any of his cool comments.

My original context was PHP but I tried to have it a generalized, so in PHP context "cache" is an xml or text or html file having database records and is saved on the server, so if the cache file exists we pull it and save server's time or else we connect to database and retrieve records. Unlike Flash or iPhone applications, since web is stateless so caches and proxies can't be in memory all the time so instead we rely on these files.

1) Within StartupCommand, a CacheProxy is registered (intercepts), and based on the parameters/variables (params become path to the cache.xml), if it finds (aka HIT) it simply echoes the content (with CacheMediator and CacheView) and returns the function before even it executes addSubCommand calls for Proxy and View, this is where we save execution and database fetch time.

2) If Cache doesn't exists (aka MISS), it goes ahead with those addSubCommands, creating model and view, this time View while displaying output to the user sends the output buffer to it's Mediator (through an Interface variable which Mediator set itself inside onRegister function hence exposing only Interface functions, view doesn't know about it's mediator). Mediator then talks to the CacheProxy with the output buffer for the cache file along with params.

3) If a request to insert a new record comes in (handled by a command), meaning the cache becomes dirty and unusable, it calls the function on CacheProxy to delete the cache file and inserts the new record (through a Proxy), the next request for the records will automatically re-create the cache file as explained above in (2) and will be reused as explained in (1).

In ApplicationFacade I've created a flag to set the Caching true or false and above steps check for this flag before execution, hence offering a single point of control for caching. Thanks again Cliff for your insight. I've tried to use and incorporate as much as I can from what I've learned from AS3 and Objective-C port into a stateless system and it has been fun doing a complete full fledged database application in PureMVC along with caching mechanism.

I've chosen PureMVC-PHP port after a long careful thought, I've used CodeIgniter and read about ZendFramework plus others, but ZendFramework is too heavy and processor intensive, and we look for the efficiency and shortest possible server execution time, can't afford heavy processes. CodeIgniter is fast but we want Extra Fastest, CodeIgniter has lot of utilities and functions that comes in the package and at the same time it comes in our way, I wanted just the vanilla core of MVC, and add utilities and libraries in our own way (and only if it's really really required). PureMVC doesn't come in our way, it gives us the decoupled approach between different parts of the system and then allows us to build on top of it on our own.

Thanks to Cliff and Hasan for bringing PHP port to life.

Hi Cliff:

My context is basically PHP, posted under, http://forums.puremvc.org/index.php?topic=2021.0 but wanted to have your opinion in PureMVC way.

Thanks

Hi:

I'm trying to work out a best approach for pulling content from cache before it connects to the Database (Proxy modules), I'm testing few ideas but I'm not sure which one is the best and the right approach.

1) Registering a CacheProxy that will check if the cache file exists and pull it or else register DatabaseProxy and Mediator and handle the request. (but I feel I'm coupling model with view because the cache files are basically view files).

2) Registering a Mediator with view component and view component will check if the cache file exists or else it will request mediator to register a proxy followed by calling a data request function on it, Proxy will send the Notification on data retrieval, and the same mediator will respond to notification and will set the data on the view component (kinda long way).

3) Current status of the system, I'm receiving the score request inside a command, say ScoreCommand and inside I'm registering a ScoreMediator and ScoreProxy and calling a retrieveRecords function on ScoreProxy for which ScoreMediator will respond to its notification, should I do if an else statement within command to check if cache exists before I even register ScoreMediator and ScoreProxy.

Thanks for any input, I look forward to feedback in language/platform independent manner, i.e. not the PHP or any other language way, the PureMVC way to handle Cache Mechanism.

P.S. I'm cautious about registering ScoreProxy, I want to register it only if I needed a connection to the database in case of "CACHE MISS" because it creates a database connection inside it's constructor.

isn't it supposed to be the __toString() function?

I understand your point, simplicity is the key to understanding at first,

I was testing across all browsers, a customized implementation of javascript framework, didn't change a bit on the framework itself but added a layer (UIComponent class to be inherited by all view components with event dispatcher functions plus others) on the view side to handle the browser differences, and facilitate the communication between view and it's mediator, and it works in IE too but not for Camino. I'm researching on it, will updated if I come across for a solution.

            if(document.addEventListener){
                document.addEventListener('DOMContentLoaded', function(){
                    ApplicationFacade.getInstance(ApplicationFacade.NAME).startup();
                });
            } else if(window.attachEvent) { //IE
                window.attachEvent('onload', function(){
                    ApplicationFacade.getInstance(ApplicationFacade.NAME).startup();
                });   
            }

Hi Cliff,

I agree it's simple plain javascript, Inside Camino the problem actually lies in DOMContentLoaded event, otherwise it's working fine in other browsers.

           if(document.addEventListener){
                alert('executes')
                document.addEventListener('DOMContentLoaded', function(){
                    alert("does not execute");
                    ApplicationFacade.getInstance(ApplicationFacade.NAME).startup();
                });
            }

Any other event I can use to test for Camino?

Solved:

Solution:

1) instead of instantiating objects inside constructor, instantiate objects directly while defining them in the second block {} inside puremvc.define.
2) Call constructor like this -> view.component.a.call(this, 'param1'); and initialize your variables through the constructor.

after some research in the doc file, I've found the answer, in case I specify my own constructor, I've to call parent constructor manually, but this brings up another problem,

Call super constructor:
view.component.a.call();

The problem is that I've some objects getting instantiated inside "class a", and in my extended "class b", I'm not inheriting them and they're coming off as null.

Please advise.

Hi Guys:

Thanks for the demo, it works fine on major browsers but not working in Camino 2.1.2 (MAC), Any suggestions to work this out.

Thanks,
Saad