With my Notification Queue I also considered using a mediator, because it can send and receive notifications.
But, shouldn't a mediator be a mediator for a view component and not a chain/queue?
The chain/queue also is mainly about data loading and having to wait for that. Therefor I fount the Proxy better fitting for the job. The only downside is that I have to use a command to let proxy goto the next step.
How do you guys think about this?

I think this is very useful. It's always good to think before you go straght to development. It's just a thing you need to learn.
I usually make a lot of notes for myself. I use uml class diagrams a lot to put a lot of the info of your outlines in. I also make little notes of processes. A simple example from my Memory game (it's in the GameCollection demo)

All the cards are layed down
card.TURNED event
  send CARD_TURNED
  CardTurnedCommand
  If(firstCard == null)
    firstCart = turnedCard;
  Else
    secondCard = turnedCard
    Send CHECK_CARDS
    CheckCardsCommand
      If correct score++
      Else score--
        removeCards

To explain again why singleton is bad for PureMVC:
- Every "module" (separate pureMVC) always exist. So when you have you widget application, a widget never get deleted after use. Waste of disk space.
- It's just as easy to do
facade = ApplicationFacade.getInstance("uniquename");
then is is to do:
facade = new ApplicationFacade();

Like I sad in this topic:
http://forums.puremvc.org/index.php?topic=235.0

Interesting literature:
http://www.ibm.com/developerworks/webservices/library/co-single.html
http://steve.yegge.googlepages.com/singleton-considered-stupid

Ok. And how does the use of singletons in PureMVC violate this?

A Singleton always exists, which you don't want if you have multiple PureMVC's parts which you can close and open.
The global access isn't necessary because you can easily pas a reference trough the framework.



I just got my Modular PureMVC version trough the unittests. So I'll be posting it soon.
To start of the right way, because this version is different to the original, there is no official support for it.
I will post a demo, and I updated all the comments in the classes, but that's it.

Seperating it into seperate/multiple pureMVC's helped us
There now is a Mutliton version made by Cliff and I made a non singleton/multiton version.

I've finished my singleton less version a few weeks ago as well. Made a demo as well. But couldn't post it because it was based on version 2.0 which wasn't released yet.
I knew I should have posted some explanation so that people knew it was coming.

It's good to see we both came to the same solution

The only differences:

• What is this appFacade parameter used for? I just use this as the instance.
  

:

public function Facade( appFacade:IFacade ) {
instance = appFacade;
initializeFacade();
}

• Instead of setFacade I use the following syntax, just personal preverence.

:

function set facade(facade:IFacade):void;

• In the 2.0 version IMediator, IProxy, ICommand extend INotifier, so the casts when setting the facade become unnecessary.
  

I see the version2.0 unit tests are online, so I'll try to test my version as soon as possible.

Okay, I understand and respect your priorities.
I will try to go ahead with my plan and build it. This will give us more insight and than, when the time comes we can possible integrate it in the main PureMVC version.

Is there a possibility to make this version as sort of a port? So that it is always open for the public? Or do you prefer seeing it being build first?

Okay... but can we start a discussion about that than?
Because I don't think that's the right solution. Just like I explained here:
http://forums.puremvc.org/index.php?topic=235.0#msg907

My biggest question is, what is the advantage over a singleton less version?

Correct me if I'm wrong but if you make it multiton you still have to pass a reference to parts like the notifier subclasses. Which is the same problem I have with a singleton less version.

The notifier has a direct/fixed reference with a facade singleton. Since it can only have one link you would have to copy the notifier to link it to a other facade. You then understand that you also need to copy all his subclasses. etc etc.

But could you think of another solution than?

Hi guys,
I'm trying to extend the framework so that you can choose to not use singletons.
http://forums.puremvc.org/index.php?topic=235.0

Changing the concrete Facade, Model, View and Controller is no problem, but the Notifying system worries me.
Because a lot of classes (MacroCommand, SimpleCommand, Mediator and Proxy) extend the Notifier class. It's impossible to change it without having to create copies of his subclasses.

I'm thinking about the following options:
- Copy Notifier, make facade changeable (By param in constructor of public property), copy all it's subclass to extend it.
- Copy all subclasses of Notifier and change the facade (less clear I guess)
- Change all the pureMVC classes so that you can give almost every class a reference to the facade. (But this is useless for the normal pureMVC)
- Make this into a alternative version of PureMVC
  (Unless one less someone has a better idea this seems the best option, pureMVC just doesn't seem flexible enough)

(I can't make a facade singleton for every sub MVC because this Notifier can only be hooked to one facade. Than we would still need to copy the whole framework for every sub MVC. )

A possible way to make the notifying system in pureMVC more flexible is to use compilation instead of extension to add Notifying capabilities. (Like you can use a custom subclass of EventDispatcher in as3.0)
This way I could extend the notifiers (MacroCommand, SimpleCommand, Mediator and Proxy) and change there notifier via there protected notifier property.
This seems okay, but this involves changing the whole framework, in my opion it's better to change it to a singleton less framework right away.

Do you guys have any ideas?

Many thanks,
Peter

Challenge accepted

But may I suggest you think about the possibility to use non singletons as core.
Because, well, I don't see why not. (except for all the documentation and ports that would need to be changed)

I'll send a mail later today.

diegovolpe,
The solution seems strange and it seems specially made for this module loading function in flex. Making a sub mvc just seems a lot more natural.

Cliff,
You mean the following idea?
http://forums.puremvc.org/index.php?topic=229
Only the first posts are about what I mean, but he ruined the whole discussion with this idea to put the facade, view, model and controller in one class.
So I wanted to make a fresh topic about this.

No, Multitons are not a good solution. Most submvc's only exist temporarily and a singleton/multiton that always exist is therefor not a good choice.
There articles on this topic are very interesting:
http://www.ibm.com/developerworks/webservices/library/co-single.html
http://steve.yegge.googlepages.com/singleton-considered-stupid

The main 2 reasons for posting this idea are:
- Checking if someone didn't already made it.
- Checking if I'm not missing a big disadvantage of problem

If nobody made it already and nobody sees a problem in the idea I want to develop it anyway.
I've already made notes in the framework to check what I actually need to change.
And with these unit test you created I should be able to test it very easily.

I think it's great that you're putting so mush time into this. It doesn't happen very often that you can discus there kind of ideas with the original creator.

diegovolpe,
I read these posts, but I didn't like the solutions. They also seemed especially designed for this module loading function in Flex. Making sub mvc's seems much more natural to me.

Cliff,
I disagree. Those minigames are only temporarily there. A Singleton/Multiton is there all the time. So the choice for singleton/multiton seems wrong.
I found these articles very interesting:
http://www.ibm.com/developerworks/webservices/library/co-single.htmlt
http://steve.yegge.googlepages.com/singleton-considered-stupid

You mean the following idea?
http://forums.puremvc.org/index.php?topic=229.0
I read it, but than he suddenly started with putting the facade, model, view and controller in one class. Which in my opinion ruined the whole discussion.

The main reason for posting my idea is to check if someone didn't already do it and I wanted to check if someone knew a big disadvantage that I'm possibly missing.

So I gues, if no one knows a big problem with this idea I'm going to try and create this.
If I understand correctly I can now easily test if it works with these unit tests you made.

I think it's really great that you are putting so much time into this. Not often you can discus these kind of things with the original creator.

I'm thinking about making a singleton less pureMVC version. This because I want to be able to make sub PureMVC's.
We where building a very large game. This game had several mini-games and a pda that all had a lot of there own logic.
Because we wanted to be able to test games separately, didn't want every game to always exist and didn't want to have to risk to have non-unique names we created sub PureMVC's.
But, because PureMVC is build with several singletons we needed to copy most of the PureMVC classes to every sub PureMVC.
Another problem with singletons is that they don't get removed, so they always remember data. This forced us to build in our own destroy methods in the framework.
We felt like the only reason for all these problem's was that it is based on singletons.
We think that if you pass out all the members the correct references the framework should work as well.

Benefits
- SubPureMVC's without framework copies.
- More separation options.
- Les change off name conflicts.
- Easier unit testing.

Downsides
- Little risk on multiple instances of application facade, view, controller and model.

What are you guys thoughts about this?