Well, yes, it is a Flex application.  The components are written in AS.  I think I overly simplified my example as later I realized what I described shouldn't be so difficult.  These are high level state changes.  A view class doesn't contain the controls for manipulating itself.  A separate dashboard class does.  So when a control is changed on the dashboard, a notification is sent from the dashboard Mediator and then picked up by the appropriate view Mediator(s).  So since the dashboard class and the passive views are separate, I think implementing Flex View States between them is hard to do without breaking either OOP or MVC conventions (ie just becoming an ad-hoc mess).  I really want them to be independent for the very reason that if I remove the dashboard, there isn't much coding overhead.  Now don't get me wrong, I use Flex View States where I can.  But the "currentState" change would still be precipitated from an event outside the actual view class whose state is changing.  Ergo the need of Notifications.

Now, if my problem really were as straightforward as hide/show toggles, I could just make a look-up table and have the ApplicationMediator process that and send hide/show notifications to the view mediators.  Or better yet, this situation would allow me to use Flex View States because in theory the application view would just toggle the visible properties of its sub-view components, assuming they are in its display list.  If my application were this simple that is.

Right now I have three separate applications, all using essentially the same components and very similar business logic.  But their frameworks are all written completely differently.  In the future it may be necessary to combine them under a monolithic shell application.  But for now they exist in independent browser windows.  I repeat, we plan to convert this to a multi-window AIR application in the future.  So right now, I need to think about that.  Of course, I want to avoid inner-platform effect and keep things as simple as possible (ie why make a system that simulates user-interaction when direct user-interaction itself will suffice?).  But I need a smart way to control a myriad of view combinations programatically.

These combinations are coming from the database.  So depending on what the application receives from the database, it needs to layout appropriately and update appropriately with new queries.  And it's that update part which I want to do right.  I can handle making Flex View States for each individual view component and having its mediator receive a "currentState" value via notification; it's the PureMVC level where I am wondering what to do.  BTW, before I end this with an oversimplification again, there is a reason why I can't use "currentState" (unless I want like 20 or so state declarations per view class).  Some of these views have their own sub-elements that can be toggled.  And again, the views don't control themselves.  The dashboard does.  And the dashboard must be surgically removed from one application that is otherwise essentially identical.

Anyway, if any of the above thinking seems wrong-headed, please let me know.

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.

Awesome.  This is actually exactly what I was wondering about.  At the start the best practices gave me the impression that the concrete facade should be minimalist but along the way me and others on my team have allowed stuff to creep in there.

So we have mostly favored the AppStartUp Command but it has bloated (and spilled over into facade startUp()).  I have personally moved a lot of command registration and proxy registration from AppStartUp into the initializeModel()/View() methods.  But your Startup MacroCommand is very appealing--I  actually remember it now from a tutorial I looked at a year ago.

By the way, am I right in assuming that the facade methods are not ever meant to be overridden except in very rare cases where you might want to modify the core PureMVC logic/behavior for some reason?  For example, inserting your own class as the View singleton.

Anyway, thanks.  I felt this was a very basic question and now that I see the answer in plain text, it seems obvious.

3) Prepare the View. This usually consists of registering Mediators, and upon registration, Mediators frequently request data from the already-registered Proxys.

One thing I want to clarify.  In step 3 you are talking about Facade.initializeView() correct?  The thing that gives me pause is that this method does not have local access to any view components.  Unlike startup() which is passed a reference to the Application view component.  As a result, I have been registering my ApplicationMediator in startup() and then having ApplicationMediator finish registering the remaining Mediators for its internal parts.  I am uncertain now if this is the most logical way.

I will try to order the book this weekend.  It will take at least a week to get here from overseas.

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.

Thank you!  I wish we'd had this conversation a long time ago.  We've already screwed this up with past applications by cowboy coding in a vacuum, but I've insisted that we do some design work before coding this time.  The design is hard (because I am not an application architect) but I can see now that the maintenance will be so much better!

Thank you guys, it sounds like you are telling me to go for it despite my reservations.  Admittedly, my reluctance is due to improper implementation of a lot of PureMVC classes that I know I can't extricate without a lot of work.  Nevertheless, there are some view/command classes that I could share.  And the model tier I have already made great efforts to separate already.  So, for my application projects, I am planning to have a lib folder with the following:

/libs
PureMVC.swc
Loadup.swc
AppCommonModel.swc
AppCommonViewCommand.swc
AppCommonComponents.swc

PureMVC and Loadup are just themselves, as .swc for convenience (Cliff, it sounded like you ultimately approve this, but let me know if I misread). 

AppCommonModel.swc holds the Proxies, VO, and whatever utils I might have exclusive to their function (eg: configuration .xml, enumeration constants, etc). 

AppCommonViewCommand.swc will have Mediators and Commands that go with view components I need in these different applications (regardless of whether their view components are implemented differently for different platforms--the public functions the Mediator calls on the view component will be the same).  Most of my Commands are used for deferred instantiation (I register Mediators, Proxies, and view components at run-time right now) and are easily shared as well, I believe.

Finally, AppCommonComponents.swc will be common view components written in .mxml or .as for these apps.  I might replace this .swc with a different one for mobile apps, Air, etc.

So each application will have its own ApplicationFacade, but apart from that, in theory, could have all its other framework classes in .swcs.

This is the approach I have come up with after reading your feedback.  If you have anything to add, or if you think I have strayed from your original advice, please let me know.

I also need to find out what happens when you set lib references to not be merged into code...

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?

Ok, point taken, and to be honest I do like the purity of the Facade as the only singleton.

Allow me to be pedantic and repeat/emphasize something Cliff said: the Facade is not the only singleton.  Controller, Model, and View are also singletons.  It's just that we access them via Facade.  This knowledge has been helpful for me.

Singleton proxies have been the bane of my existence.  But God Object is a misnomer.  Malignant Cancer Object is more accurate (with the added bonus of being a TLA).

Philip, thanks for the reply.

I have to admit I am still pretty confused about everything.
First of all, I am not registering anything to respond to LOAD_RESOURCE_TIMED_OUT, so if that notification is firing, I am not aware of it.  I assume the monitor proxy however is aware of it.

Like I said, I am only responding to the failed/loaded notifications of individual proxies for debugging.  These are the same notifications registered with loadup's command structure:

command code (ApplicationStartupCommand):

:

...
facade.registerCommand(SystemConfigProxy.LOADED, LoadupResourceLoadedCommand);
facade.registerCommand(SystemConfigProxy.FAILED, LoadupResourceFailedCommand);
...

debug code (ApplicationMediator):

:

override public function listNotificationInterests():Array {
  return [
    SystemConfigProxy.LOADED,
    SystemConfigProxy.FAILED,
    ...
  ]
}
//and
override public function handleNotification(notification:INotification):void {
  var name:String = notification.getName();
  var body:Object = notification.getBody();
  var type:String = notification.getType();
  switch (name) {
    case SystemConfigProxy.LOADED: {
      startUpMessage += name + "\n";
      break;
    }
    case SystemConfigProxy.FAILED: {
      startUpMessage += name + "\n";
      break;
    }
    ...
    case LoadupMonitorProxy.LOADING_FINISHED_INCOMPLETE: {
      Alert.show("One or more necessary resources could not be loaded:\n" + startUpMessage, "Application Startup failure");
      break;
    }
    case LoadupMonitorProxy.LOADING_COMPLETE: {
      Alert.show("All necessary resources were loaded:\n" + startUpMessage, "Application Startup");
      break;
    }
  }
}

I have simplified the above as there are several proxies but they all follow the same basic idea.  The debug message collects the notification names and I use that information to find out which ones failed and which ones loaded.  The Alerts show this debug string.  As you can see, in the case of LOADING_COMPLETE the debug message contains XXX.LOADED notification names only.

Even if there is a FAILED notification from one of the proxies it comes in immediately.  The URLLoader requests are not hanging up indefinitely (ie not timing out--I get an immediate IOError because the resource does not yet exist on the server).  But the monitor proxy seems to respond either immediately or 300 seconds later for mysterious reasons.  When all the LOADED/FAILED notifications have come in, sometimes it sends LOADING_FINISHED_INCOMPLETE immediately, other times it waits 300 seconds before sending LOADING_FINISHED_INCOMPLETE.

I realize that Loadup doesn't know/cannot know how long it should take to load a resource, and that is why it uses its own timer.  However, and please correct me if I am wrong, but if all the proxies registered with the monitor have sent in their respective LOADED/FAILED notifications and thus triggered their LoadupResourceLoadedCommand/LoadupResourceFailedCommand then shouldn't Loadup know that it does not need to wait for a timeout?  Shouldn't it send a LOADING_FINISHED_INCOMPLETE notification immediately (if one of the responses was a failure)?  I believe that the retry count is 0.  It is the default setting.

I hope this has clarified my point of confusion.

Like I said, depending on the day, hour, and minute, the server response times may vary 500-3000 milliseconds.  But the responses generally come quickly.

Finally, I am not implying that I think something is wrong with Loadup.  I just want to confirm the expected behavior in the situation I described above.

(note: all LOADED/FAILED notifications' name values are unique to the Proxy that sends it--that's not the problem :-)

Thanks!

Note to moderator: can we move this thread to the correct forum?

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.

Thanks for the advice, Cliff.  I will indeed stick with the simple implementation in this case then and just make a note along the lines of what you said in the class descriptor.  Back in the day when I used Cairngorm there were times I broke the rules regarding view/helper classes because it made sense from an OOP perspective.  I guess this gave me pause because I perceived it as part of the model tier.

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.

Thanks for the reassurance.  Basically, one notification per command is still the convention.  I'm not going insane.

Thank you!  I will loosen up a bit about constructor arguments then, and try to use it as a means to pass simple initialization parameters to mediators, etc. instead of the cumbersome notification dispatching I've used so far.  I don't think the notification method was bad, but it did result in a lot of boilerplate to achieve what I felt should have been a very simple task. 

Furthermore, it allows me to handle the more complex requirements of the above loop registration in a simple, straightforward way.  I seriously had no idea how I was going to dispatch a notification using the type parameter to set the "sharedType" when the target mediator didn't yet have any "type" to discriminate.  Anyway...

I always appreciate your insight!