Mediators and Components Help to Understand

[citizen_conn]

Hi. I am very new to puremvc and trying to establish the architecture for an online questionnaire done in flash.

AS in previous iterations I have extended the TextField class to make a CustomTextFieldClass with some predefined properties such as textField.stylesheet = [global class].styles.css; I would then pass in the textField content as a string in the constructor.

In my puremvc version, I feel this would best be done with a TextFieldMediator, which has access to the proxies which contain the text I need (from the xml), the stylesheets, etc.

My questions are as follows:

1. Considering that I need access to those proxies, the best way to do this is to have a mediator for that component right?

2. I will for sure need to have multiple instances of this component within whatever parent viewComponent, so I think its silly to have a mediator for each view component and have to register each one. How does one go about adding multiple instances of a view component that are all children of the same mediator?

I was unable to understand how this should work by reading the best practices PDF so any help is greatly appreciated!

Ted

[citizen_conn]

Ok. So after sleeping on it and dreaming in puremvc, (the view was the most prominent class), I have come to the following conclusion:

Something such as a CustomTextField class should not have a mediator associated with it. I should apply the stylesheet to it on it's parent class, or pass it in to the CustomTextField class as an argument.

Mediators are only when a view component needs to communicate with the rest of the application in which case a Mediator should mediate those needs with the rest of the application via notifications. Otherwise a regular component class should suffice.

Any confirmation/clarification would be great.

[sasuke]

> Something such as a CustomTextField class should not have a mediator associated with it.

I'm with you on this one; that would be going too far IMO. Mediators should be used when a view needs to offload it's mediation logic to an entity since placing all the event handling code in the view itself or in a separate ad-hoc script file would be too limiting.

> Mediators are only when a view component needs to communicate with the rest of the application in
> which case a Mediator should mediate those needs with the rest of the application via notifications.
> Otherwise a regular component class should suffice

Again agreed; async communication using notifications is the way to go and is much more preferred over having global stores in your application to share data between components. The way I work with PureMVC is to delegate all the PureMVC event handling stuff to the mediator and in case there needs to be performed some screen specific logic, again delegate the control back to the view.

:

public class MyMediator extends Mediator {
  // Constructor

  public function get module():MyView {
    return viewComponent as MyView;
  }

  override public function listNotificationInterests():Array {
    return [MyFacade.DATA_RETRIEVAL_SUCCEEDED];
  }

  override public function handleNotification(notification:INotification):void {
    switch(notification.getName()) {
      case MyFacade.DATA_RETRIEVAL_SUCCEEDED:
        var vo:MyVO = notification.getBody() as MyVO;
        module.processDataAndManipulateView(vo);
        break;
    }
  }
}

<mx:Application>
  <mx:Script>
  <![CDATA[
     public function processDataAndManipulateView(vo:MyVO) {
     // Perform view specific logic with returned data
     }
  ]]>
  </mx:Script>
  <!-- your view components/controls go here -->
</mx:Application>


[puremvc]

Mediators are only when a view component needs to communicate with the rest of the application in which case a Mediator should mediate those needs with the rest of the application via notifications. Otherwise a regular component class should suffice.

Any confirmation/clarification would be great.

Yes, this is correct. Encapsulate that view component behavior wherever possible!

@sasuke, This is good descriptive code underlining this view component encapsulation principle.

-=Cliff>

[brianjolly]

Picking this discussion back up...

So far we've decided to to create a mediator for the component we've been talking about, to encapsulate the communication of the children in the component with the rest of the app.

The one thing we're struggling with is best practice for setting values in very simple view components like our CustomTextField class. In the past our CustomTextField class accesed a style sheet in a global variable. This was very convenient since it didn't require us to pass the style sheet around to get it to the CustomTextField instance.

Currently we're passing the style sheet into the CustomTextField's constructor, when it's instantiated by it's parent Sprite. It is getting a little cumbersome passing the style sheet around though, and seemed much simpler to have the style sheet globally accessible.

A mediator for CustomTextField seems overkill since it's instances aren't really going to need to communicate with the application. What would be best practice for passing data (in this case css) to this simple view component?

Thanks for all the comments so far!

[puremvc]

Global variables are something to avoid if at all possible, but for every facility in a language there is a purpose. Styles is a good example of that. As long as your custom text field itself isn't referencing that global stylesheet, but having it placed on it, the component remains reusable. How you find the stylesheet to add the style to the component is up to you and if you're doing it via a static reference more power to you. Icons and app-wide constants and another good example. No need to 'pass around' the reference to the sheet. It's a boundary thing. The guts of the app don't need to know about it.

That said, a mediator for a single text field, while entirely possible, is really too fine a granularity. Usually we would mediate a whole form, encapsulating the behaviors of the fields of the form inside the form component itself.

In such a typical setup, the mediator would deliver a value object to the form, which would have its properties bound into the form fields for editing. The data on the VO would be modified by the internal actions (binding or methods) of the form component, which would send a 'save' event when the user completes the edits and clicks save. The mediator would then take the edited VO from the form and save it by calling a proxy method.

-=Cliff>