Home → Robotlegs 2 →

Add properties to mediators during the mapping process

• Edit

brndn

27 Mar, 2013 10:44 PM

Hi there
I am fairly new to RL2 or 1 for that matter.

I have an obscure question, I have am working on a fairly dynamic application, a lot of the view generation process is done using factory utilities or methods. Driven from a viewState manager of sorts.

The view associated with this mediator below, has sub views, generated from a data response.

Please see below.

` [Inject] public var viewStateManager:ViewStateManager;

override public function initialize():void { super.initialize(); services.getData(new ServiceEvent(completeHandler, faultHandler), viewStateManager.currentView.dataQuery); }

private function completeHandler(event:Event):void {
    event.currentTarget.removeEventListener(event.type, completeHandler);
    serviceDataArray =JSON.decode(event.currentTarget.data);
    addSubView();
} `

Is there anyway I can dynamically modify properties of the mediator assigned to each view.

` public function addSubView():void { for(var i in serviceDataArray){ var clazz:Class = viewStateManager.currentView.subView

var subView:IView = new clazz();

  **  var mf:MediatorFactory;
    mf.getMediator(clazz) **

---

    view.addItem(subView);
  }
} `

or would I be better just assigning the property to view directly. like this below and then pluck it off the _viewComponent via the mediator.

` public function addSubView():void { for(var i in serviceDataArray){ var clazz:Class = viewStateManager.currentView.subView var subView:IView = new clazz();

---

  **  subView.dataSet = serviceDataArray[i] **

---

    view.addItem(subView);
  }
} `

Any seasoned advise would be much appreciated

many thanks.

1. Support Staff 1 Posted by Ondina D.F. on 28 Mar, 2013 12:00 PM

   

   Hello,

   If I understand your use case correctly, you can make use of robotlegs 2’s hooks and viewProcessorMap.

   I’ll try to exemplify that through some pseudo code.

   DynamicVO is a value object class holding a _dynamicProperty, that DynamicView will use to set its properties (something like your subView.dataSet)

   SubViewsModel provides an array of subViews.(your viewStateManager?)

   In ParentMediator I set dynamicVO.dynamicProperty to some random value (in your case that will come from your service call) and pass a subView (in my example it’s DynamicView) from subViewModel.dynamicSubViews to ParentView, which will add the subView to the stage.

   DynamicMediator’s hook will run the moment the mediator is created (actually before mediator’s initialize() method) and will access DynamicView’s API initView().

   DynamicVO is injected into DynamicView and will reflect the changes made in ParentMediator (the random values).

   Mappings:

   injector.map(SubViewsModel).asSingleton();
   injector.map(DynamicVO).asSingleton();
   
   //DynamicView will be injected with DynamicVO
   viewProcessorMap.map(DynamicView).toInjection();
   
   viewProcessorMap.map(IDynamicView)
       .toProcess(new MediatorCreator(DynamicMediator))
       .withHooks(DynamicMediator);
   

   ParentMediator:

   private function onAddDynamicView():void
   {
       dynamicVO.dynamicProperty = "dynamic "+(Math.random() * 255).toString(16);
       var clazz:Class = subViewModel.dynamicSubViews[0];
       var subView:IDynamicView = new clazz();
       view.onAddDynamicView(subView);// ParentView adds DynamicView
   }
   

   DynamicMediator:

   public class DynamicMediator extends Mediator
   {
       [Inject]
       public var view:IDynamicView;
       
       override public function initialize():void
       {
       }
       
       public function hook():void
       {           
           view.initView();
       }
   }
   

   DynamicView:

   [Inject]
   public var dynamicVO:DynamicVO;
   
   public function initView():void
   {
       dynamicViewInput.text = dynamicVO.dynamicProperty;
   }
   

   Normally, I wouldn’t access a model(or a service) inside of the mediator like I did above. I would let a command access the service, set the results on a model, that would dispatch an event with a payload when the data changes. The mediator would listen to that event and read event’s payload and pass it to the view, which would create and add the subViews.

   Details about view processor map and hooks:

   https://github.com/robotlegs/robotlegs-framework/tree/master/src/ro...

   https://github.com/robotlegs/robotlegs-framework/blob/master/src/ro...

   Hopefully, that wasn’t too confusing :) Don’t hesitate to ask more questions!

   Ondina

   • Edit

2. 2 Posted by brndn on 28 Mar, 2013 05:23 PM

   

   Hi Ondina
   Thank you for your detailed example and an insight into the view processor map and hooks.

   Is there a reason why you would not just use the mediator to access the model singleton without injecting the view into the mediator as defined in the view processor mapping pattern? Also is there some kind of tight coupling issues getting properties from an injected model via a mediator.

   then to fire data into a view you could use the viewComponent reference that gets passed into the mediator.

   override public function set viewComponent(view:Object):void { super.viewComponent = view; }

   Just wanting to understand why the extra legwork with the suggested approach.

   Cheers

   brndn

   • Edit

3. Support Staff 3 Posted by Ondina D.F. on 28 Mar, 2013 07:10 PM

   

   Hey brndn,

   Is there a reason why you would not just use the mediator to access the model singleton

   The reason is tight coupling, as you have guessed. I don’t have the time to get into details about this right now, so I’ll just give you a few links to Best Practices and discussions on this forum about the topic (inject model into mediator):

   http://knowledge.robotlegs.org/kb/reference-mvcs-implementation/can...

   http://knowledge.robotlegs.org/discussions/questions/309-inject-mod...

   https://github.com/robotlegs/robotlegs-framework/wiki/best-practice...

   http://knowledge.robotlegs.org/discussions/questions/451-does-model...

   http://knowledge.robotlegs.org/discussions/questions/1030-mvcs-arch...

   http://knowledge.robotlegs.org/discussions/questions/1072-models-an...

   http://knowledge.robotlegs.org/discussions/robotlegs-2/861-where-mu...

   If you still have any questions after reading all of the above, please let me know.

   then to fire data into a view you could use the viewComponent reference that gets passed into the mediator.

   Sure, you can do that.
   Accessing view’s API from its mediator is absolutely ok and a recommended practice as well.
   I guess, I wanted to avoid accessing subView’s API in the ParentMediator, that’s why I suggested my approach. And also because hooks and the viewProcessorMap are new features in rl2 and I wanted to see how they would solve a use case like yours ;)

   Ondina

   • Edit

4. 4 Posted by brndn on 28 Mar, 2013 09:06 PM

   

   Ondina
   many thanks for the links.
   I do like the credit card analogy.
   quick and cheap solutions, with future consequences.

   unfortunately, I have ridiculous deadline for this application's phase 1 delivery.

   But will definitely revisit parts of the application when I have some breathing room, to refine some of the patterns and implementations.

   Or maybe ill jus do the leg work now.

   anyway, your advise has been very helpful.

   • Edit

5. Support Staff 5 Posted by Ondina D.F. on 29 Mar, 2013 09:24 AM

   

   You're welcome!

   I'm closing this discussion for now. Feel free to reopen it in case you have more questions or you need further assistance with this issue. Please open new threads for new issues.

   • Edit

6. Ondina D.F. closed this discussion on 29 Mar, 2013 09:24 AM.