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: viewstack, deferred mediator creation  (Read 10810 times)
sitron
Courseware Beta
Newbie
***
Posts: 4


View Profile Email
« on: March 17, 2008, 02:33:29 »

hi everybody!
sorry, another post about deferred creation... but i still haven't found what i m looking for.
i have a viewStack with deferred creation of views and mediators. The views send an event upon "creationComplete" to create their mediator. This works ok.
in one of the views i have a control to pass to another view so flow looks like: view -> mediator -> notification (carrying a VO) -> instantiation of the new view -> creation of its mediator. The problem is that this new mediator doesn't have access to the passed VO as it is not directly created by the notification but after the view is created. How would you deal with that?
Logged
Rhysyngsun
Courseware Beta
Sr. Member
***
Posts: 51

Nathan Levesque

 - rhysyngsun@gmail.com  - rhysyngsun
View Profile WWW Email
« Reply #1 on: March 17, 2008, 04:10:00 »

In the command you use to create the new mediator, after it has been instantiated, send a mediator creation complete notification, which the original mediator listens for. When the original mediator receives this notification, send a new one with the VO which the new mediator listens for. It's a bit complicated for sending just a VO, but it keeps the mediators decoupled from each other.
Logged

sitron
Courseware Beta
Newbie
***
Posts: 4


View Profile Email
« Reply #2 on: March 18, 2008, 01:21:06 »

thanks for the answer.
It makes sense, though i have 2 concerns:
- how is this going to scale up? if i have 10 views in my viewstack won't it be quite a mess?
- i m wondering if your solution really decouples the 2 mediators. It seems a bit odd that an "event dispatcher" has to know something about the receiver (listen for its onCreationComplete, then send the VO).
what do you think?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: March 18, 2008, 04:53:16 »

When the new mediator has been registered, simply send another notification with the vo. The new mediator hears and obeys. No coupling, that notification could go anywhere.

No need to listen for creationComplete.

-=Cliff> 
Logged
sitron
Courseware Beta
Newbie
***
Posts: 4


View Profile Email
« Reply #4 on: March 18, 2008, 10:38:50 »

sorry, maybe i just don't get it.
doesn't that mean that the 1st mediator has to check whether the new mediator is already registered before sending its notification with the VO?

it's like: ok, the user pressed that button, i want to send that event with the corresponding VO, but wait, is the receiver already registered?

i m not a purist, just trying to get it the best way i can.
thanks for your help.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: March 18, 2008, 11:50:12 »

you said:

view -> mediator -> notification (carrying a VO) -> instantiation of the new view -> creation of its mediator.

  * ViewComponent dispatches an event
  * Mediator hears, takes the data from the ViewComponent (or custom event) and sends Notification
  * Notification is an array containing a reference to the new component, and the VO
  * Command responds:
      * Creating Mediator passing in new component
      * Registers Mediator
      * Sends new Notification that the new Mediator is interested in, with VO as body
  * New Mediator, just registered gets this Notification and acts on it, setting the data on the new component.

Is it possible that this same event happens again later, but we don't know if it creation has taken place or not?

  * ViewComponent dispatches an event
  * Mediator hears, takes the data from the ViewComponent (or custom event) and sends Notification
  * Notification is an array containing a reference to the new component, and the VO
  * Command responds:
      * If (! facade.hasMediator(NewMediator.NAME) )
         * Creating Mediator passing in new component
         * Registers Mediator
      * Sends new Notification that the new Mediator is interested in, with VO as body
  * New Mediator, just registered gets this Notification and acts on it, setting the data on the new component.

This is business logic, which belongs in Commands.

-=Cliff>


You weren't clear on your flow in the original post and the above is how I understood it. Something has happened at the view and a mediator needs to be
Logged
sitron
Courseware Beta
Newbie
***
Posts: 4


View Profile Email
« Reply #6 on: March 18, 2008, 02:35:18 »

thanks so much for taking the time to answer, i really appreciate.

ok, i think you re right, i didn't explain it well enough in my 1st post.
situation is quite simple: 1 viewstack, 1 viewstackMediator, 2 views, 2 viewMediators. 1 of the views with a control saying: "show the other view, and pass this data (a VO)".

flow is: view1 -> event -> view1Mediator -> notification with VO (no reference to the new component) -> command (viewStackMediator: change view, view2Mediator/view2: display VO data). Only that view2 is created when the viewStack changes, and its mediator after its "creationComplete", which means that it does not exist at the time of the command.
So i need at some point to stop the flow, store the VO and wait for the view2Mediator to be created.

i can find many workarounds to this, but i was wondering what was the best way to handle it.
thanks again.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: March 18, 2008, 02:53:41 »

If the flow I outlined on the previous post (or some variaton therof) doesn't work, then it sounds like this data needs to be placed on a proxy and retrieved by the new mediator when it is registered.

-=Cliff>
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #8 on: August 16, 2008, 04:18:47 »

Here's a link to the new FAQ entry for the deferred instantiation issue:

http://puremvc.org/content/view/91/185/

-=Cliff>
Logged
Pages: [1]
Print