Over 10 years of community discussion and knowledge are maintained here as a read-only archive.
1) I should be going with multicore I suppose? What would the different cores be?
2)I'm thinking each lecture should have it's own proxy. The lecture view/mediator will then be associated with the current lecture proxy for the selected course which points to a lecture proxy. Which lecture is pointed to will change with time. Does this make sense?
3)All lecture proxies will send notifications, but the The lecture view/mediator will only be interested in notifications coming from the ”current” lecture. Is there a way to only subscribe to notifications from that particular proxy or do I have to subscribe to all lecture proxies?
Why do you feel you need different cores?
You can have a single proxy that manages access to the list of lectures and keeps the notion of the current item in the list. You don't necessarily have to have a separate proxy for each lecture.
Use the third parameter to sendNotification (the type parameter) to pass the id of the lecture. Then have the mediator look at that property and decide if it needs to act on it.
Why do you feel you need different cores?I guess for the very reasons you mentioned. Smiley
How do you choose a proper "granluarity" of proxies when you have hierarchical data structures though? What should be taken into consideration? Are there any rules of thumb here?
often when you're dealing with asynchronous communication you have requests and responses paired with those requests. I'm used to using the following syntax for such requests: asyncMethodName([args], callback:Function).
The reasons I mentioned were why you'd use the MultiCore version instead of Standard. They weren't arguments for defining different cores within your app. You can write an app that has only one core with MultiCore.
The only problem with this is that the only actor that hears about the result is the caller. So, if you had a Mediator do this to a Proxy to tell it to fetch an object or list, then that Mediator would be the only one to hear about the return. What if three other Mediators also need to hear about it? Now it must be that first Mediator's responsibility to not only handle the return but also to notify the other Mediators.
If you only want the caller to act on the response, use the AsyncToken pattern to track and respond to the appropriate caller. Have your calling mediator pass its name on the proxy's method call, have the method set the name onto the AsyncToken returned by the call, and on the result, have the proxy get the name back from the token and set that as your third notification parameter. Then have the mediators who are interested in that note act if their name matches the note's type parameter.
That problem is easily solved by first invoking the callback and then sending the notifications.
If I have multiple mediators of the same type I would have to make sure each mediator instance has a unique name, right? Is there a problem with passing a function instance instead? That way the uniqueness would be inherent in the design, if you know what I mean.
I do want to keep my domain model separate from pureMVC as far as possible, but at the same time it seems so natural to I modifiy the relevant classes of my domain model (AppModel, CourseModel, LectureModel etc.) into PureMVC proxies.
I would define one or more VOs that represent the data structure and have the Proxies tend these. The VO can be passed freely about the tiers of the app and even be given to a view component. The Proxy acts as the keeper of the VO as the Mediator acts as the keeper of the view component.