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: What is the best way to make non-view initiated updates to the model?  (Read 7077 times)
doofus
Newbie
*
Posts: 3


View Profile Email
« on: July 10, 2008, 04:19:06 »

Here is the situation:

I am running a simulation with PureMVC where the model is updated independently of the view. I would like to use the notification mechanism of PureMVC to make timed updates to specific objects within the model from remote resources.

The closest approximation I found is the RSS data feed demo. In this demo, a timer object is created by a proxy and a method of the proxy handles the timer events to make updates to the model elements associated with remote data resources. This has a few limitations and creates a situation where I would need to propagate the flash event notification interface throughout the model proxy classes where updates are needed to model vo objects.

Instead, I would prefer to somehow have the model define specific update notifications to listen to with a simple context identifier like the one used by the observer class.

The best practices guide suggests that the proxy should only send messages and not receive them. But it seems cumbersome and incorrect to setup the view and controller to distribute these update notifications to the model.

Maybe somebody here has encountered a similar situation, or has an idea of how to handle this while maintaining the integrity of the PureMVC paradigm.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: July 10, 2008, 05:46:30 »

First question: you say your model is updated independently of the view and later that it seems incorrect to have view or controller handle the update.

So, where do the updates come from? The model itself? If so have one proxy retrieve another and get manipulate it.

-=Cliff>
Logged
doofus
Newbie
*
Posts: 3


View Profile Email
« Reply #2 on: July 10, 2008, 06:21:37 »

Yes, updates are defined and generated by the model itself. Maybe I am overlooking something but the proxy classes are not able to receive notifications like the mediator classes. The proxy classes would still need to implement the same functionality as the mediator.

The mediator class seems to have everything needed to do this cleanly and simply, except that it is considered as being part of the "view". Right now I am contemplating using a combination of a proxy and mediator class to distribute notifications to the model. The proxy would generate notifications to send to mediator instances. The mediator would contain a reference to a specific model object, and would cause the model object to be updated from a remote data source. So this class would act as both a mediator and proxy. Maybe this could somehow be interpreted as breaking the MVC paradigm, but if viewed abstractly, it still maintains separation of MVC components because this type of mediator would only interact with objects in the model, and has no relation to the presentation layer.
« Last Edit: July 10, 2008, 06:50:17 by doofus » Logged
doofus
Newbie
*
Posts: 3


View Profile Email
« Reply #3 on: July 10, 2008, 07:31:08 »

Ok, I just finished implementing the interaction sequence described earlier, where a proxy sends regular timed events to a mediator that in turn updates a model object.

It was actually very simple to code and now the simulator can generate complex notification sequences from within the model to have the model dynamically update selected groups of model objects. As the simulation progresses, different groups of model objects can be selected for updates.

It was surprisingly simple to implement, and all I had to do was fold an existing proxy class into a new special type of mediator that only interacts with model objects, thus preserving the integrity of the MVC paradigm.
Logged
Pages: [1]
Print