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: the role of the singleton in puremvc  (Read 9203 times)
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« on: January 31, 2008, 05:11:58 »

I was wondering why you chose to have to Model, View and Controler classes as singletons??

because the facade is a singleton, and the 'best practice'  route is through the extended facade, then the facade can manage its MVC unique instances. It could also manage its concrete ApplicationFacade's unique instance, allowing access to it by the Notifier class.
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #1 on: January 31, 2008, 05:55:30 »

having the Abstract Facade manage its concrete subclasses' unique instance also means that the subclass would not need to have its own singleton method...
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: January 31, 2008, 05:59:24 »

They are Singletons because I want to insure there is only one instance of each within the application.

As for Facade providing access to its instance by using the Notifier class, I'm not sure how that would work.
Notifier grabs the Singleton instance of whatever Facade exists using Facade.getInstance. Being a framework class it can't know the name of your concrete Facade any more than Facade can.

-=Cliff>
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #3 on: February 01, 2008, 04:19:52 »

thanks for answering... this is really just academic interest as to why you made your decisions the way you did (I find that coding is a compromise between performance/file size/code readability/dev history and even aesthetics.

this is how I might have considered doing it (and I'm not at all suggesting that its better, just a different set of compromises)

instead of having five singletons (M,V,C,Facade and outside the frame work - AppFacade), they could be boiled down to one (I'm going by the guideline of as few globals vars as poss)

so if the MVC and F are put in the same package, (eg org.puremvc.core) and put in the internal namespace (except for the F which is still public) only the F can instantiate them. This means that the F can control their creation, and since F is a singleton MVC are also.

Then, if instead of containing its own instance, the F contains the instance of its (Final) subclass ApplicationFacade (passed up in the constructor)

final class ApplicationFacade{
   
   public function ApplicationFacade(){

      super(this)
   }
}

public class Facade implements IFacade
   
   public function Facade (f:IFacade){

      if (instance != null) throw Error(SINGLETON_MSG);
      instance = f;
      initializeFacade();   
   }
}


What this means is that the singleton would be invisible outside the framework ( OK, the Facade.getInstance could still be invoked, but a custom namespace would solve that if neccessary).  The FacadeApplication would still throw an Error if there is an attempt to create more than one and the only getInstance() methods called are within the frame work when either a Proxy Mediator SimpleCommand or MacroCommand are created
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #4 on: February 01, 2008, 05:06:47 »

yeeeerrrrs,

hold on, thats not quite right ;~)

Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #5 on: February 01, 2008, 05:17:22 »

there is a  call to the view singleton in the initializeController method that I missed... oh well
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #6 on: February 01, 2008, 05:39:40 »

so you could expose a getView method... but maybe we're loosing something there.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: February 01, 2008, 06:34:17 »

Part of the framework plan is that the developer be able to extend or replace any framework class, which makes it difficult to do what you're saying here.

I'm all about reducing the use of global vars as well, but PureMVC best practices make it clear that you don't ever really use the M,V, & C Singletons directly, and the Facade is used by actors who have it as a collaborator by design.
All notification participants need to agree on notification constant names so it isn't unreasonable to expose those globally.

The pattern of Singleton use in PureMVC is quite different from other frameworks such as Cairngorm where view components feel free to access and rely on various Singletons, and even bind to properties on them.That makes the view components and the model less portable and maintainable.

-=Cliff>
Logged
theFlashWizard
Jr. Member
**
Posts: 13


View Profile Email
« Reply #8 on: February 06, 2008, 04:20:50 »

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.
Logged
diegovolpe
Newbie
*
Posts: 7


View Profile Email
« Reply #9 on: February 07, 2008, 03:52:37 »

I think there was a misunderstanding about the way we implemented:
# Flex modules have unique behavior compared to separate flash swfs:
- When you need optmization, they must run in the same context, so they can share classes.
- It's impossible to use "sub mvc's". When a singleton is created in flex, the next instances will return the first loaded instance, even if its in a separate module (when using optimized modules and  runing in the same context/appDomain)
Ps.: If you disable module optimization you'll have to embed the flex framework classes in each module.

I totally agree with fleecie. The main idea was:
Create a AbstractFacade and Facade extends AbstractFacade and implements the singleton (default usage)
When you need to use it in flex modules, your applicationFacade wil extend AbstractFacade and not Facade. You'll have to implement the singleton pattern too (to have one instance per module).

That's all you have to do (if there were no dependencies on singletons).

As Cliff has sad, changing the framework default implementation is out of the question, so whe had to change the aproach.

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



View Profile WWW Email
« Reply #10 on: February 07, 2008, 09:33:25 »

This discussion (or one just like it) has been going on in the thread next door, so to speak: http://forums.puremvc.org/index.php?topic=235.0

FlashWizard has accepted the challenge to create a Utility that implements the MVC classes as non-singletons and a demo that will show it doing its sub-mvc magic.

This idea has floated around for awhile and really been off-limits since changing the core framework really is out of the question at this point. If this utility proves to be useful for Modules or for doing Flash apps that load separate swfs each with their own PureMVC apparatus, then it might be pretty cool. It'll go into the repository and everyone can take it off-the shelf and give it a whirl if they need it. Otherwise, things proceed as normal.

If it does work, it'll really show off the extensibility of the framework by showing the very core actors being replaced.

-=Cliff>
Logged
Pages: [1]
Print