Cliff
Yes, I agree about the utility carrying out the retries.

But note that the demo only has a retry button so that the developer using it can appreciate what is going on.  In a real app, with the existing utility, it is perfectly reasonable that the app would automatically decide whether to retry and how often to retry - no button for a real user.

----Philip

Cliff
Could you just clarify as to whether you mean that the utility would automatically invoke the retries?
----Philip

Bevan
Fair point, we can add to todo list, for action at next opportunity - make retryCount accessible, per your suggestion.  Meanwhile, and in any case, you can maintain your own count in the app class that invokes retry, for example if it is occurring in a single mediator.

This is probably a good point to also mention Derek's comment about offering a controlled method for resetting the StartupMonitorProxy for reuse.
----Philip

You refer to 2 approaches.  I do it the second way.  Proxy has the array collection as you say.  Proxy also has a map by record id to reference each record in the array, to facilitate direct update of a record.  Proxy has to maintain the map in line with each insert/delete to the array collection.
Regards
    Philip

Derek
Just a few points in response to your above post, relevant if you are doing some work on this.

In the monitor, isLoadingFinished() does not test for complete, it just means this iteration is finished and the app has the option of retry.  allResourcesLoaded() would be appropriate test for completion.

retryLoadResources() does start a process that checks all resources but any that are already loaded are not re-loaded.

Good luck.
    Philip

Steve /Trilec /.../Cliff
Evolution of startup manager, as I recollect it

• General Discussion forum, topic: "first project with puremvc", started by danieleUg
  
• read through this forum, if you want to know the full story (in excruciating detail dare I say!)
  
• I think Cliff coined the name StartupMonitorProxy
  
• the problem to be addressed: a number of resources to be loaded at startup, using separate asynchronous requests, manage the loading in a structured way, with a design that would have general applicability
  
• Daniele created the AppSkeleton demo and this evolved to a final version, with an important contribution from meekgeek along the way; the demo includes a resource dependency feature in that resources are sequenced and a resource can be marked as blocking the load of follow-on resources until that resource has been loaded
  
• I needed a more generalised solution to dependencies between resources, and enhanced the code accordingly, within my application, and presented the revised set of core classes
  
• as yet, there was no utility, these were applications with some common classes and common code fragments
  
• Cliff was pushing for a utility, for ease of re-use, and I set about doing that
  
• meanwhile meekgeek came in with some enhancements to cater for a timeout requirement that he had
  
• I incorporated the timeout feature and then an associated retry feature and also catered for the case where a resource load fails; I also built in some robustness and proper separation of utility from application
  
• this became the utility, with the StartupAsOrdered demo to illustrate use of the utility.   
  

When is the utility appropriate?  In my case, an application with accounting data, I wanted to load a variety of data at startup, using separate asynchronous requests, this data to then form an integrated object data model, so...

• load in-progress accounting documents, but must have chart of accounts loaded first
  
• chart of accounts requires that master currency info has been loaded
  
• various kinds of reference information must be loaded before any of the above
  
• and so on.
  

So, if you want to load an integrated data model, in separate chunks, then the utility could be useful.  You must look at your particular requirements and see if it has a role.

As regards documentation of the utility

• see the API docs, available by viewing within the manifold project environment, or by asdoc from the src in the download zip
  
• the demo app is key to understanding how to use it
  
• my replies to some queries earlier in this thread may be useful
  
• the source code of the utility is not large
  
• Steve (and others), if you would like to contribute to the documentation, that would be great.
  

If there are people who have used the utility and have found it worthwhile, let us know here on this forum.  That would be a great way of seeing the kinds of problem that it is suited to.  Of course, let us know if you tried it and it failed to deliver - that would be important too.
    Philip

Kouri
Just one small point in reply.  The StartupAsOrdered demo is narrowly focussed on demonstrating use of the StartupManager utiltity.  While it may be a useful reference, it is not intended to be a reference application for any real problem domain.
    Philip

Derek
The difficulty with passing args to load() is that load() is called from within the startup manager and it doesn't have knowledge of the args.

The complexity of providing this knowldege to the manager, say through some additional property of the StartupResourceProxy, is hard to justify, when the app's own proxies can more easily provide themselves with the knowledge and can pass information between themselves as the loads progress.

Also, on reading your post, I wondered whether you are using the startup manager to monitor a single proxy?
    Philip

trilec
Have you looked at the StartupManager Utility and the associated StartupAsOrdered Demo?  I know it maybe doesn't meet your needs, but I just want to be sure you've checked it out.
    Philip

Hi Joe
What about the following approach.

animations requires config
music requires config

Let the animations proxy have a property that references a config object (approach 1) or maybe even references the config proxy directly (approach 2).  Let the music proxy have a similar property.

Presumably the config data, when loaded, is available via the config proxy.  With approach 2, the config data is therefore available to the animations proxy also, and ditto the music proxy.

If approach 1 applies, in the load completion process of config proxy, before sending notification that config has loaded
- retrieve a reference to the animations proxy and set the config-related property on it
- ditto the music proxy.

What do you think?
    Philip

Sorry about no replies here; I didn't notice this thread until late yesterday.

Steve
Don't know if you still have this query.  Anyway, some points that might be relevant

• Reference the API docs for StartupResourceProxy
• No reason why the app's own resource proxies can't be created dynamically, provided they are named uniquely and implement IStartupProxy
• The associated StartupResourceProxy objects can also be dynamically created
• A fresh StartupMonitorProxy is required for each case of resources to load; many apps only need this once, at startup; however, if the needs arises from time to time during app running then just use the startup manager again, but you must recreate StartupMonitorProxy and must  register that new instance so that it replaces any previous one.

James
Take 'load model resources'.  These must be loaded before Update UI can occur, I presume.  So, a run of startup manager could accomplish that, with each model resource having a proxy etc.  Update UI and 'login' sounds like they would not use startup manager.

Maybe 'load connection settings' is a set of resources (one or more, each with a proxy), subject to asynchronous loading that could use the startup manager; maybe login cannot occur until this completes.

See the comment above about using the startup manager more than once.  Maybe you would need to use it twice; once for connection settings and once for model resources.

I hope this reply has not missed the point.
    Philip

Kouri, I don't know if this is relevant and you may already know this anyway.

Be aware that with viewstacks you can't just register mediators any old time - the view component must first have been created (creationComplete) - otherwise the reference to the view component is null and this will affect the instantiation of the mediator.  See other postings in these forums regarding deferred instantiation and registering mediators etc.

I just want to add a correction and an addition to my post above regarding timeout and the StartupManager utility.

1. Forget the setForRetry() idea.  Better to leave the resource status as timed out.  Then the client app simply invokes retry by a retryLoadResources method on StartupMonitorProxy.  The client doesn't have to reset individual resources.

2. We need to allow the client app to notify when a load process fails, e.g. <resourceABC>_LOAD_FAILED and have a new class in the utility StartupResourceLoadFailedCommand to handle such notifications.  Such failures are like timeouts in that they result in the LOADING_FINISHED_INCOMPLETE notification from the utility.

Regards, Philip

Thanks to meekgeek for sharing his work incorporating timeout into the previously posted startup monitor code.  I am here responding to Cliff's "can you reconcile..." above.  I am interpreting the timeout requirement as set out in the meekgeek posting.  There is no connection with the app resource's actual loading process, which, once started, runs on independently of the startup manager.

The Startup Manager Utility is currently the following 4 classes:
StartupResource, StartupMonitorProxy, IStartupProxy, StartupResourceLoadedCommand.

Taking this new work into account, I think the list of classes would become:
StartupResourceProxy, StartupMonitorProxy, IStartupProxy, StartupResourceLoadedCommand, StartupResourceTimedOutCommand; plus retain StartupResource, see below.

StartupResourceProxy
StartupResourceProxy has the advantage that the client app can name it and can retrieve it, assuming it is registered of course, and can thus have access to certain properties.  I would prefer not to require that the client's own resource proxy has to extend StartupResourceProxy, since that may impose on the client app design.  Instead, say the constructor is:

:

public function StartupResourceProxy( proxyName:String, appResourceProxy :IStartupProxy )
The cient app must instantiate its app resource proxies before the StartupResourceProxys.  The loadResources method of StartupMonitorProxy can now invoke the client loads via the IStartupProxy reference held by the StartupResourceProxy.  The StartupResourceProxy and the appResourceProxy must have different names, assigned by the client app.

In thinking about the internals of StartupResourceProxy, I think it makes sense to keep the StartupResource as a separate class: the proxy is a front for the StartupResource, the data property of the proxy is of type StartupResource, the proxy constructor creates the StartupResource. So, that takes us to 6 classes in the utility.  StartupResource would no longer have the 'proxyName' property.

Let this StartupResourceProxy have
- public methods for client use, e.g.: read/write 'requires', read/write 'timeout', read accessors for 'status', maybe also a setForRetry() to cause status change from TimedOut back to Empty
- internal methods for utility own use, as in access from StartupMonitorProxy.

StartupResource
This has a new timeout property, and a new TIMED_OUT status value, with associated access methods, per meekgeek's posting. The setStatusToLoading method starts the timer.  On timeout, a notification is sent e.g. STARTUP_RESOURCE_TIMED_OUT.  This is handled by the StartupResourceTimedOutCommand, which in turn calls the StartupMonitorProxy#resourceTimedOut method.  Questions: is there a non-zero default timeout? a timeout of zero means we ignore timeout? For now, my default would be zero.

StartupMonitorProxy
- resourceList is now a list of StartupResourceProxys
- let addResource() continue to have just one arg; let the client app set the timeout for the resource directly via the StartupResourceProxy
- resourceTimedOut(): set resource status, add to timedOutResourcesList
- allResourcesLoaded() is renamed to something like isLoadingFinished(), because some resources may have timed out and other resources may require those and so on, so we may be finished even though all resources are not loaded.

How does the client app know we're finished but not complete? Say we send a LOADING_FINISHED_INCOMPLETE note instead of a LOADING_COMPLETE note.  In the incomplete case, we could send in the note body an array of the incomplete StartupResourceProxys, to make it easy for the client to set those for retry if desired.  And if retry is desired, the client invokes monitor.loadResources() again to try the outstanding resources.  I know Cliff expects features that cause the utility itself to retry a number of times before reverting to the client, but I'm ignoring that for now.

IStartupProxy
Continues to just have the 'load' method, I don't see an example use of 'onComplete'.


Cliff/Meekgeek/others - any comments on the above?  Subject to your comments, if this is worth doing, it may be easiest for me to incorporate this into the utility at this time, since I have my hands on it.

Regards
    Philip

Jud
Presumably, as an alternative to an init method, you could pass the file location info as an argument to the constructor of ConfigProxy.  This makes it very plain that it is essential to that proxy.  I'm assuming this does not contravene best practice.
    Philip