I am going to have a chance to redesign/refactor one of our poorly implemented PureMVC applications in a few weeks and am trying to determine how to address what has been a huge problem.

First, we started with just a general application with several toggle-enabled views.  These toggles are controlled by A_VIEW_SHOW/A_VIEW_HIDE notifications which the view Mediators use to hide/show their viewComponents in response to user actions (the UI is a dashboard view).  Additionally, there are other notifications for changing view modes unique to each view (eg: color/black&white mode, etc.). 

Next, it was necessary to make a sort of report application.  The original thinking was that each page of the report showed different information in a logical sequence instead of forcing the user to click buttons to manipulate the view.  So, instead of Show/Hide CheckBoxes for the UI, it would have a Next/Prev page pair of Buttons.  Page 1 would have A and B visible.  Page 2 would have B and C visible.  Page 3 would have D visible.  My co-worker implemented a very complicated system to do this which records what views are visible or invisible and dispatches the Show/Hide notifications as appropriate.  But it's a holy unmaintainable mess.  Everyone, even the original author, wants to redo it.  Since he is leaving, the task falls to me.

I don't think there is anything wrong with the design of the first application.  Every minute change of view is precipitated by a user event.  But with the second semi-automated report application, there needs to be a way to organize things so that when the user clicks one button, the overall view changes (as though he had pressed several all at once with the dashboard UI).  To clarify, the first application has a dashboard and a dashboard mediator to control things.  The second application does not--it just has prev/next buttons and can cycle those views automatically on a timer.  Otherwise the features of the two applications are basically the same.

So right now I am looking into the Finite State Machine utility to see if it might give me a eureka moment.  It hasn't.  But that is because I have yet to make a connection between the demos and what I am trying to do here.  But is this the way to go?  I'm still going to spend the next few days trying to figure out FSM but if there are better approaches for what I want to do, please tell me. 

PS Please keep in mind the most complicated design pattern I have used up to this point is Factory (and I guess MVC since that's what PureMVC is).

PPS The main thing that is giving me pause is this: each set of report pages is actually a dynamic list.  Report1 might be pages [A&B, B&C, D] and Report2 might be pages [A, B, C&D, ... X], etc. customizable to infinity.  So my situation is that the various view states and combination of view states is very definitely NOT finite.

Ok, this is sort of a back to basics question but, put simply, what belongs in your concrete facade's init() method other than a sendNotification() to trigger your AppStartUp Command?

And what should you put in your AppStartUp command that shouldn't go in your concrete facade's initializeController/View/Model() methods?

The reason I am asking is that all kinds of initialization code is creeping into these two spots (with some bleed over into initializeController/View/Model()) and I need to implement some kind of best practice or standard for my project.

For example, here are some common things being put willy-nilly in the framework startup logic:

• Flashvars proxy registration
• Class variable/Singleton settings (eg: ToolTipManager.showDelay = 0;)
• Context menu configuration
• All kinds of view class Mediator registration -- does the Mediator need data from a Proxy to initialize?  Yes?  Then wait for the proxy notification to register it.  No?  Then register it in the concrete facade... wait, is this really the best way?
• LoadUpUtility stuff -- currently done in AppStartUp Command

Some of the stuff related to the Flex framework I feel like it should perhaps go in the Application mxml file.  Maybe configuring the ContextMenu should as well.  But sometimes the ContextMenu depends upon the flashvars which I want to access via the FlashVarsProxy... so into the framework code it goes!

Suffice to say, I'm curious where people would put the above logic to keep things tidy and sensible.  This may require a review of what the concrete facade functions role should be, etc.

This question is not: Should I put the PureMVC framework in an .swc to share among projects.  The answer to that question is yes, and I do.

The question is about my specific framework classes for my applications.  The situation has arisen that we need to make a "light" version of our horrible enterprisey PureMVC-abusing electron consumption CPU temperature elevation engine (aka, our application).  But the PM wants us to share code across these two projects as much as possible in a way such that if I make a change to one class it will affect both projects.  Nothing revolutionary here.  Ordinarily this is done with a library project.  I totally support this and have no problem putting our utils, view components, and service code into an .swc.

Where I am hesitant, however, is when it comes to also bundling the framework Mediators, Proxies, Commands, etc. selectively into an .swc so that the "light" application shares framework code with the "big" application. 

• PureMVC.swc?  Yep. 
• LoadupUtil.swc?  Absolutely. 
• Some_common_mediators_commands_and_proxies_but_not_all.swc... uh.

Correct me if I am wrong, but isn't this a bad idea?  Shouldn't I keep the two code-bases for the framework classes (extending PureMVC classes) entirely separate even if they are redundant and even if updates might require that I copy changes into multiple locations?  What if later I am tasked with coming up with 50 "light" applications all using the same source but with only minor differences in content?  Does the same principle apply?

Finally, assume that the differences in these applications are significant enough that I can't use a configuration file or some other means to compile different versions of the application from one single project.  We tried that and it failed and now everyone here knows what inner-platform effect is.

Has anyone been in this situation?  And what did you do?

I am not sure if this is the right forum to ask this in, but I am having trouble with LoadupUtil today.
I currently have two .cgi data services which are not ready yet though I have implemented their Proxies anyway.
This isn't a problem because it gives me a chance to test the application's fail state.

I am using LoadupUtil to sequence my initial proxies.  The flow is not that complicated, but I like Loadup anyway because it keeps things simple (although the boilerplate is non-trivial).

On Friday, the two requests to the yet-to-be-implemented server .cgi return a failed notification and then almost immediately after that LoadupMonitorProxy would send a LOADING_FINISHED_INCOMPLETE notification.  I thought that was good.  We know the 2 services failed immediately.

But now today it is acting differently.  The two .cgi proxies both return a failed notification immediately but LoadupMonitorProxy does not fire any notification at all.  If I wait for some minutes then finally it will send LOADING_FINISHED_INCOMPLETE as a result of LoadupMonitorProxy.timeoutTimer timedOut() handler.

Obviously, something is different (I think).  But it shouldn't be.  So first, before I can start debugging this, I need to know what exactly LoadupMonitorProxy is supposed to do.  Which of the two above behaviors is correct?  Should it be timing out or should it be finishing incomplete immediately?

Finally, could the response time of the successfully loaded resources affect this?  So far that is the only thing I can think of that might have changed... the server response times change daily.

I have a challenging view implementation to convert into the PureMVC architecture.  First I will describe the specifications and then get into what my problem is and then address why I am now asking myself the above question.

Requirements and background:

1 The view class shows a scatter plot of identical icons.
2 Each icon is linked to a set of images that are updated on the server in real time.
3 When the user moves the mouse over an icon, a small panel "tool tip" with a thumbnail image appears (via Image.source = url).  The thumbnail url is static, but its image on the server gets overwritten periodically.  This is nice.
4 When the user clicks the icon, the thumbnail "tool tip" gets tacked down, enlarged, and remains visible even when the user moves the mouse away from the icon.
5 If the user moves the mouse over an icon whose "tool tip" has been tacked down as above, then the tacked down panel simply gets highlighted (ie, it doesn't display a second tool tip).
6 When a "tool tip" has been tacked down buttons appear in the panel allowing the user to display images previous to the most current one.  These images are *not* the thumbnail.
7 All tacked down "tool tips" should poll the server for the updated list of image urls for that icon.  These image urls are cycled through by the user and their image displayed in the tacked down "tool tip".  These images on the server are not updated.  Only the list of urls to be cycled through is.  This is not nice.

The data model consists of a master xml list that simply gives information for the scatter plot.  Inside the master list is a url pointing to the thumbnail image as well as a url pointing to another xml file containing information about the list of viewable images for that icon (necessary for cycling through past images when the user interacts with a tacked down "tool tip").

eg:

:

<master>
  <icon>
    <thumbnail>www.mydomain.com/imageId/thumbnail.jpg</thumbnail>
    <imageList>www.mydomain.com/imageId/imageList.xml</thumbnail>
    <!-- and additional assorted data for the scatter plot -->
  </icon>
  ...
</master>
and

:

<!-- www.mydomain.com/imageId/imageList.xml -->
<!-- this content is constantly changing -->
<imageList>
  <image index="1" filename="11.jpg" time="2010/01/01 10:10" />
  <image index="2" filename="14.jpg" time="2010/01/01 10:17" />
  <image index="3" filename="01.jpg" time="2010/01/01 10:21" />
  <!-- and more, of variable length -->
</imageList>

The master.xml file is loaded once at application start.  However, imageList.xml updates constantly.
Performance issues mandate that I only query and poll imageList.xml files when there is a tacked down tool tip that requires it (remember, when an icon is hovered over, the thumbnail image url will do).  I cannot simply get all the data all at once constantly.  The previous programmer addressed this problem by having a URLLoader inside the "tool tip" panel class.  The panel and its parent view component both know whether it is tacked down or not.  Each tool tip panel would do its own polling and handle its imageList.xml data on its own.  No proxies.  I have to say that as I am refactoring these classes, I am very tempted to do the same.  Which leads me to...

Why I am asking myself the question:

I cannot come up with a solution using proxies that does not make the implementation (in my mind) vastly more complicated than the previous programmer's approach.  How am I supposed to handle all these imageList.xml queries using proxies?  When the "tool tip" is tacked down, dispatch an event to the scatter plot view's mediator and then send a notification to do... what?  Register a new proxy for that piece of data, start a polling routine, and then send the result back to the scatter plot view's mediator?

icon (click event) > scatter plot (tacks down "tool tip" panel, sends icon click event) > mediator (sends notification) > command logic registers imageList proxy > imageList proxy onRegister() starts url loader server request > url loader receives server result (event) > imageList proxy sets its data to URLLoader result (sends notification) > mediator (handles notification, proxy data is in body) > scatter plot (sets previously tacked down toolTip's imageList property to received data) > toolTip shows updated images when user interacts with it

This seems like a very complicated chain to achieve the same result as what was previously just a simple implementation in the "tool tip" panel's logic.  Let alone the rigamarole I have waiting when the user closes a tacked down "tool tip" and I have to then unregister its imageList proxy.

And finally, when the component programmer is making these classes, how on earth is he going to be able to implement and test functionality with dummy data?  The above process seems to mandate that he also program with the framework logic in front of him (at least) if not actually running on his machine.  Up until now, I have been able to stipulate data setters for a view component, tell the component creator that when testing locally he just needs to plug in certain dummy data I provide and get the component to work sans mediator and sans PureMVC and then when he is finished I can plug it into my mediator source code and it works.  Can't have everything, I know, but still...

For these above reasons I am doubtful about using a proxy for all data interactions.  Maybe there are exceptions?  At least in this case I don't know what to do.  One option is anti-PureMVC pattern.  The other is a convoluted mess.  That said, I am leaning toward prioritizing simple implementation over correct implementation.  Please tell me I am wrong and that I can have both.

I appreciate any suggestions and feedback.

Quite by accident, I found this in our code base:

:

public class AppStartupCommand extends SimpleCommand implements ICommand {
  ...
  override public function execute(notification:INotification):void{
    switch (notification.getName()) {
      case ApplicationConstants.START_UP: {
        //40 lines
      }
      case ApplicationConstants.LOAD_CONF: {
        //5 lines
      }
      //approximately 100 more lines of case statements, approx 10 case statements total
      //mostly registering mediators, proxies, and other commands
    }
  }
  ...
  //subroutines... so that no case statement goes beyond more than a few lines
}

At first I was kinda horrified... case statements in execute() ?!  But then I remembered that I had considered doing this myself in the past.

Is there any good rule of thumb for how to decide when multiple notifications should share the same command as above, and when a notification should have its own command?  I am about to recommend to this person that they implement a separate command per notification since there is no single piece of shared logic in any case statement (ie: nowhere do case 1: ... case n: call a common sub-routine).  But on the other hand, the entire class file is only 350 lines long, and there are no other command classes cluttering the code base... and the code is sequential.  I'm just worried about it getting out of hand.  I don't want to see a project later where every notification goes through one monolithic command.  Honestly, I have always had just one notification per command.  Any logic that couldn't handle a given structure of body data needed another command/notification.

I have to admit, though, at its current scale, his method was also a lot easier to implement than using the Loadup utility.  (basing this assumption on the amount of time he spent coding this versus the amount of time I spent struggling to comprehend Loadup tutorials).

Ok, first, I have a way to do this, but I want to see if this is really the best way to do things.

I have two types of mediator classes.  One is a generic view, the other is a generic control panel.  Each view/control panel acts as a pair.  These pairs have the exact same function except that the data they work with is different in each case.

Because of this, I have implemented just two classes: ViewMediator and ControlPanelMediator.  The application as a whole displays data sets A, B, and C.  I have instantiated my view/control panel pairs with names like: "ViewMediatorName/A" and "ControlPanelMediatorName/A".

Now the hard part is for a given ControlPanelMediator to affect a given ViewMediator I need to use the type parameter to make sure unrelated actors of the same class aren't also effected.  In other words, ControlPanelMediator/A needs to control ViewMediatorName/A (for example, telling it which attributes in the common data model to display, whether to be transparent or not, etc.).

Currently, I am having these two mediators extract a "sharedType" variable from their names upon registration. 

:

override public function onRegister():void {
  //mediatorName = "ViewMediatorName/A"
  //sharedType = "A";
  //same thing for ControlPanelMediator
  sharedType = mediatorName.split("/")[1];
}

Then when ControlPanelMediator sends a notification, it sets the notification type to this variable, and the ViewMediator with the same sharedType variable handles the notification (all other ViewMediators ignore it).  I think that part is relatively sound.  But it's the actual method of extrapolating this "sharedType" variable from the mediator name upon registration that I am unsure about.

Is this the best way to do this?  I was thinking I ought to explicitly set the "sharedType" on each mediator... but how would I do that without making a big mess?

Remember, the point is I don't want to subclass these for each data set used in the application because the data sets are identical in structure.

Ok, so I have come across something in our code base and it has caught me flat-footed.
Its audacity is so stunning that I don't know what to say to the person who implemented it.
So please explain to me what is wrong with the following:

The Mediator class has a global variable pointing to a proxy class.

var _proxy:MyProxy = new MyProxy();

Later, the Mediator class simply calls _proxy.retrieveData() (for example, in the onRegister() method).

Inside of MyProxy, a URLLoader instance retrieves the data from the server and then sends a notification. 

The Mediator picks up the notification, passes the data from _proxy to the viewComponent, and moves on.

Everything works fine but you will notice that nowhere is the proxy registered with the facade.  Because I mean really, why bother?

How do I correct this code and how do I explain the correction?  Or should I follow his example and just stop registering my Proxies when a global reference will do?  It does use less CPU cycles this way!

I have a frustrating problem that I can't figure out the solution to without breaking PureMVC convention.

I have two mediators for two separate views in the application.
One mediator is for a viewComponent that manipulates some data that eventually becomes the parameters of a server request.  This data is made from scratch.  It originates in the viewComponent based on user interaction.

The other mediator is for a viewComponent that serves as a control panel for, among other things, triggering the above mentioned server request (via a "ServerRequestCommand" notification).

My problem is, I cannot think of a way to grab the necessary parameters through the parameter-setting viewComponent without just directly calling a get method on its mediator.

But isn't this anti-pattern?

:

ServerRequestCommand extends SimpleCommand {
  public function execute(notification:INotification):void {
    var params:Array = ParamSettingViewCompMed(
      facade.retriveMediator("ParamSettingViewCompMed")
    ).getParams();
    //business logic follows...
  }
}

Even if I pass the parameters in the body of the command's notification (which seems correct), that just means the problem is moved from the command class to the control panel mediator class that sends the notification.

:

ControlPanelMediator extends Mediator {
  ...
  public function serverRequestButtonClickHandler(event:MouseEvent):void {
    var params:Array = ParamSettingViewCompMed(
      facade.retriveMediator("ParamSettingViewCompMed")
    ).getParams();
    sendNotification("ServerRequestCommand", params);
  }
}

Is my whole architecture screwed up?  I'd really like to get this right before implementing similar stuff down the road.

My general rule of thumb so far has been that only Proxy classes may have methods that are directly called by other actors (ie Commands and Mediators)--everything else goes through Notifications.

Ok, I am anticipating this question coming up in my project:

Why is it ok for a Command to grab a Proxy and call some method directly on that Proxy but the same thing is not allowed for a Mediator?

Ideally, Proxies do their own work, but sometimes I need to control them via a Command (for example, tell a Proxy that it no longer need retrieve data from the server in real-time; tell a Proxy to refresh its data from the server; etc.--it's always for remote data).  From what I have seen so far, it is ok for a Command to grab a Proxy and call some method implemented on that Proxy to accomplish any one of those things.  Correct me if I am wrong, please.

But for a Mediator, it is incorrect to grab its instance and tell it to do something.  Use a notification instead.

Obviously, since Proxies can't respond to Notifications there is no choice but to call a method on the Proxy instance.  But now it begs the question, so why not Mediators, too?  What's good for the goose is good for the gander, right?

Anyway, I think I am missing something here, and since I am going to have to explain this to my co-workers soon, I don't want to sputter when they make this argument.  Or even worse, I don't want to make a mistaken argument.

So again, please, tell me why it is ok for a Command to call methods directly on a Proxy but be forced to do the same via a Notification for a Mediator.  And if my question contains a false assumption, please tell me that, too.

Thanks!

Hello,

I have been trying (and failing) to grasp MultiCore architecture but want to use it badly in my current project.  However, having other deadlines, I cannot in good faith push it on my team leader yet (also I don't want to work horrendous overtime if something goes wrong).

However, we have a serious problem.  Our current app has tons and tons of classes, many of which do not get used during the operation of the application.  In fact, many of the Mediators, Proxies, Commands are not used because most users do not have have account settings permitting their use.  Nonetheless, for the application to be usable by everyone, those classes are included.

I desperately want to end this.  Eventually, I want to use MultiCore, but I just don't have time to completely scrap our existing code.  So I am looking for an intermediate but progressive solution.

Here's what I have so far:

First I want to organize the start-up logic so that it is less monolithic.  I will break up the start-up command so that it no longer registers every possible Proxy and Mediator.  I will have it simply check the account information for the user and then dispatch service-specific start-up commands that the user actually has access to.  So far, this is a no-brainer, right?

But, even doing this, I guarantee that references to unused classes will still persist in the final bytecode.  If a particular service is ever deleted, reference errors will occur in the project, headaches will ensue (because spaghetti will creep in no matter what). 

So next, without going full-barrel MultiCore, I am hoping that I can use BaseModule as a way to compartmentalize Proxies, Commands, and by extension Mediators and their view components.  I think I should be able to have a command simply load a service-specific module (BaseModule) whose only code is to then immediately register and fire its corresponding service-specific start-up command.  Remember, this command presumably holds references to proxies and mediators which will bring with it any view component code and what-not for that service.

The final trick is then to watch that class casting and constant references do not exist in the "shell" code but are really actually confined to code related to one service.  ServiceAMediator should not communicate with ServiceBMediator by doing something like this:

:

var o:IServiceA = IServiceA(facade.retrieveMediator(ServiceBMediator.NAME)).doSomething()
//by calling NAME on ServiceBMediator, I guarantee it gets compiled with ServiceA
//even if the above logic never actually gets executed...
//this may seem stupid, but this actually happens in our app
or

:

var o:ServiceBMediator = ServiceBMediator(facade.retrieveMediator(AppConstants.ServiceBMediatorName))
o.doSomething();
//obviously, casting with ServiceBMediator includes it with ServiceAMediator when compiling.
//better to use an interface if the above logic might not be executed based on account settings.
Instead, we will need to use common interfaces when necessary and preferably find solutions for our current (bad) code using Notifications rather than direct references.
Anyway, this is what I am thinking of proposing as an intermediary solution until me and my team feel confident we can re-write the current application in MultiCore.  BTW, it's not just that we don't understand MultiCore, but also Pipes, Ant, and Flex Builder project organization.

What I would like to know is if there is any thing I've missed.  Is the above a good strategy in your opinion?  Any feedback whatsoever appreciated.

Ok, I am trying to put together my first MultiCore application.  But there's one pill that I am having a hard time swallowing:

In each core's ApplicationFacade class so far I've seen:

:

public static function getInstance( key:String ) : ApplicationFacade
        {
            if ( instanceMap[ key ] == null ) instanceMap[ key ]  = new ApplicationFacade( key );
            return instanceMap[ key ] as ApplicationFacade;
        }

But these ApplicationFacades are package/core specific.  So... assuming only one instance of one core is ever around at one time, why not just return that instance?  Keep the key internal...

:

public static function getInstance() : shell.ApplicationFacade
        {
            if ( instanceMap[SHELL_KEY] == null ) {
                instanceMap[SHELL_KEY]  = new shell.ApplicationFacade();//calls super() with SHELL_KEY
            }
            return instanceMap[SHELL_KEY] as shell.ApplicationFacade;
        }

...and so forth with each core's ApplicationFacade?
Again, I know this won't work with an application like PipeWorks Prattler demo, but in my case I can honestly treat each core sub-application as a singleton.  Having to manage the core applications' facade keys outside their specific Facade class seems overly complex. 

But then, having the multiton in the first place seems irrelevant once I start to go down this path.  So what is wrong with this approach?  I feel like I am totally missing the big picture here...

Ok, I'm having issues trying to navigate from a standard PureMVC framework to a MultiCore framework.  After searching the forums, I see many questions similar to the ones I currently have already posted (particulary: "I studied the Modularity demo but I still don't understand...").

So before I add a whole list of questions, does anyone know if there is a FAQ for MultiCore?  In the meantime, I will keep searching through the forums.

Finally, what's the best place to ask questions specifically regarding MultiCore set-up and implementation in the future?

Ok, so I am currently trying to clean up the spaghetti that is our current ApplicationFacade and its immediate mediators.  Our application is dependent upon settings that are located in the flashVars of the encapsulating HTML object tag (we use swfobject if you're curious).  From those vars we determine what database the application should then retrieve its information from (these settings are downloaded from a url in flashVars).

Currently, flash vars are grabbed inside the facade class and then a url request is launched via URLLoader then and there.  When the request comes back, more fun stuff is done where the facade--which kept a global reference to the Application instance it received in the startUp() command--passes the URLoader's result to the application view component (yeah! who needs a Mediator, right?).

Well, all this works, but I feel like to is definitely not correct (correct me if I am wrong).
The place where I am particularly facing a moral conundrum is the flashvars itself.

Here's part one of my question:
I feel as though the flash vars should have its own proxy (registered in the new StartUpCommand) but flashvars comes directly from the view component via: view.root.loaderInfo.parameters.

I could just pass that object in the StartUpCommand:

:

facade.registerProxy(new FlashVarsProxy("FlashVarsProxy", body.root.loaderInfo.parameters)) //body is an instance of Application
But since its bound directly to the application instance, should it be handled inside the Mediator as a sort of public var?

And now for part two of my question:

Once I decide what to do with the flash vars, who/what should be responsible for the URLLoader request for remote variables based on those flash vars?

Again, I am leaning towards just declaring a proxy for that in the StartUpCommand and setting a search parameter based on the flash vars.  Perhaps via the FlashVarsProxy I register on the line just before it (or not)?

:

var systemConfigProxy = SystemConfigProxy(facade.registerProxy(new SystemConfigProxy()));
systemConfigProxy.dataURL = body.root.loaderInfo.parameters.serverURL; //and now wait for notification when the URLLoader is complete

Any thoughts much appreciated, no matter how detailed or specific!

Hi, I'd like to ask the community yet another question about Proxy models and the best practice.

Currently, I have a Proxy that gets its data from the server based on a search condition.  The search condition exists as a single property on the Proxy and is dynamically set by the view (Mediator).

Now, in a simple situation, like an application that searches for a person in the database by a unique ID, I think this would be fine.

But in a complex situation, where maybe the data is being queried by conditions filled out on a form, I wonder if the search condition should be encapsulated by its own Proxy (or VO).

So I'd like to get an opinion about best practice here.  In my case, I will implement the same approach for all situations.

I am thinking about 3 possible approaches:

1) all dynamic search properties will be stored on the Proxy class that requests and stores the search result from the server.  Merit: less class files  Demerit: possibly verbose Proxy

2) all dynamic search properties will be stored on the Proxy class in a VO property for that class.  Merit: simple and standard Proxy  Demerit: more class files, slight overkill for simple situations

3) all dynamic search properties will be stored on a separate search condition Proxy class.  Merit: same as 2, but this just "feels" like a better model structure...  Demerit:  same as 2

Even if you don't have an opinion about which is the best, if you can think of any merits/demerits I haven't, please let me know.
Thanks for any feedback!