Nice workaround indeed.
Yes now we came to the end to the bottom of this one!

Greets!

This is happening because mediator is not unregistered form the observers list. So it is still there even if you call the removeMediator, the same thing stands for Commands.

So as I can understand here.

 MainApp --> module interaction is done through ModuleMediator which holds the reference to the actual instantiated module. Module mediator listens to the notifications from the rest of the app?

 module --> MainApp interaction is done through event listener in ModuleMediator ?

 And how are you supporting multiple modules loaded at the same time and communication between them (if you needed this).


 

@memorycraft: As I understood you are just suggesting a bit more abstraction. But then again when you want to send a notification to some other facade instance it is required to get that instance. So the approach will be the same.

@cliff: Yes well events are a good solution but I was used to notifications for inter modular communication, but you are right. It is cleaner.

I only had requirements to comunicate with 'master' application.
Master application loads a lot of modules and each of the modules has its own facade. Some modules had to interact with 'master' application so the solution was to retrieve 'master' facade by :

:

Facade.getInstance(masterName);

masterName is constant. And then send the notification to that app. This is a bit of chaining but it is an easy way to solve the problem.

well it is a code generator for Flex. So you can use generated code instead of typing manualy your lists and forms etc..

No problem Cliff.

I'll send it to you mail.

I think I found better approach for this.
Every Proxy extends RoProxy (RemoteObjectProxy

RoProxy has :
protected var refMap:Array = new Array;

and I have 2 functions:

:

   protected function addRecord(item:Object,token:AsyncToken):AsyncToken{
      refMap[token.message.messageId] = item;
      return token;
    }
   
    protected function removeRecord(token:AsyncToken):Object{
      var item:Object = refMap[token.message.messageId]
      refMap[token.message.messageId] = null;
      return item;
    }

and then when you call delete operation for instance :

:

  public function remove(item:Object):AsyncToken{
       return addRecord(item,service.removeByPKey(item.id));
    }

and its resulthandler:

:

private function onRemoved(evt:ResultEvent):void{
      list.removeItemAt(list.getItemIndex(removeRecord(evt.token)));
      sendNotification(DELETED);
    }

For insert operation you have to return newly inserted record and then when it returns just add it to the list, update operations don't require this way of handling if you keep the reference to the object you are updating.

Thanks for the response.
Just one more thing. How you handle data mapping for pKey -> array position.
Traverse the Array?

Hello,

   I can say that this is not strictly oriented to PureMVC but since I am using it it has some relations.
I am interested in the way you handle data changes for the records that is acquired from the database with a lot of records.
For instance lets say that you are working with 10 000 records (ok there can be paging but still you want to display at least 1000 records in a DataGrid).

Proxy is responsible for comunication with the database backend and operations on the data.
Considering memory consumption it is good to bind Proxy.data to the ArrayCollection which is used as a dataProvider for a DataGrid. When user makes some change in that list, proxy has to send the request to the database to execute the operation.
When the operation is successful, there are 2 approaches that I am considering:
 - reload the data again form the database - for a lot of records it can be slow
 - or change the data directly in actionscript

with the first approach if user scrolled down to watch some records he will lose its position. With the second approach it is better for the user but it requires a lot more work.
For example, on insert service has to send back newly inserted object which can be added to the Array. On update, service has to send updated object back again and then you have to search through the array for the primary key of the updated object and replace it with the new one. Similar thing happens when object is deleted.
I am interested in the best way to handle this, so I want to hear what is your experience?
Maybe better way to store objects in HashMap?

Actually, Milos, the facade access can happen in initializeNotifier, before onRegister. You could wait until onRegister, but the following is what I did in the Modularity demo:

Yes that is ok, but somehow I like it more to put everything in the onRegister method.. It is logical place for me.

Thanks Cliff!

Well to me the most clean method is that proxies represent service objects and mediators all directly their methods and wait for notification to retrieve data.

With Commands as Responders you can end with dozen commands for one service object. For instance if you have DAO object with insert, update, select, getAll, delete methods you should have for each table all the commands that handle this and in the mediator you would have to send a dozen of notifications and also register all this commands which leads to a total confusion.

By using proxies and directly calling its methods you are having one entry point and have a clean way of knowing what to expect to be returned.

But, I didn't hear anything about IOC in Flex. I found Parsley from spicefactory.org and it looks very promising but I didn't use it. What do you think about this?

Hello all,

   I am building big application that has many modules and has very heavy database interaction. Application server is Java and for the front end Flex is used with PureMVC. I wanted to discuss about best practices in handling rpc calls. There are a lot ways to manage this but I will present ones that I consider good:
 
  1. BusinessDelegate that represents the DAO class. This Business delegate is then used in a Command to execute some of the DAO operations (eg. insert, delete, update). Mediators send notification when user requests operations. Every command is a Responder and sends notifications when rcp op is complete which mediator listens for.
     Good thing: this way it is easy to make different BusinessDelegates (WebService, HTTPService, RemoteObject) and provide it to the command
     Bad: there are a lot of Commands
  2. Proxy represents DAO class. Mediator calls the method in proxy as it would call DAO method and listens for notification that proxy will return.
     Good: very clean
     Bad: nothing special

So I am going with the second approach as I consider it better. Do you have some other ways of handling these?
I have here a so called issue if multiple mediators use the same Proxy class and they all get updated when Notification is returned. I consider this a good thing because this way the view is staying consistent and I didn't find a case when this is unwanted. But if in some case this is unwanted, all of the public methods of Proxy return the AsyncToken, so in mediator it is possible to add custom responder.

The other thing is some IOC framework that I require here. It would be great to easy (configurable through xml, or some other ways like in spring) provide to Proxy some other way of accessing the data (remoteobject, webservice, etc). So did anyone used some ioc container with puremvc?

Hola,

   I refactored some code and created Commands for loading/unloading modules. But while I was testing the solution I found one problem. After the module is unloaded next time it is loaded registered commands get called twice. I am doing unregistration of all commands, proxies and mediators that module had when it unloads.

  Right now I don't see the problem so please help 

  The code is attached to this post.

you've got a good point there!