Home → Problems →

Mediate 2 component instance of same class

• Edit

bjallow129

03 Apr, 2010 07:40 PM

Hello,

I have two components in my display list of the same type, both of type GalleryView. I want each instance to have a Mediator of a
different type. One has a GalleryView1Mediator, the second has a Gallery2Mediator. However I can't work out how to set this up. It seems there is no way for me to set up the Mediator map to look for a particular instance being added to the stage (like with Pure MVC). Only a class. I have run into the same problem with generic classes like Labels or Buttons.

I'm sure there is a way...

1. Support Staff 1 Posted by Joel Hooks on 03 Apr, 2010 08:17 PM

   

   With Button/Label (and likely your GalleryView) it is best to extend the base class if you want this sort of functionality. It is a product of dependency injection (generally) as the injector doesn't have any clear way to discern your intent.

   It sounds like your two GalleryView instances serve different purposes based on the need for different mediators. Perhaps creating a PurposeOneGalleryView and a PurposeTwoGalleryView that extends the base GalleryView component would solve your problem? Does it mean more classes? Sure, but it isn't that much more to manage and the components will be explicit. Common changes occur in the base, so that is easy to manage as well.

   • Edit

2. 2 Posted by bjallow129 on 04 Apr, 2010 10:28 AM

   

   Thank you for your reply.

   I have to say this makes me very uneasy. This seems like favoring inheritance over composition. If I have 2 buttons - One toggles when its Mediator gets a SOMETHING_CHANGE event, the other is disabled when it gets a SOMETHING_ELSE_CHANGED event, they are still both Buttons. In this case sub-classing would seem completely unnecessary - I would be sub-classing a view component to make it work with the framework which is inverting the dependency as far as I can see. Surely the view shouldn't need to change because of the framework

   • Edit

3. 3 Posted by Jason Dias on 04 Apr, 2010 11:13 AM

   

   It sounds like you shouldn't need to mediate those buttons individually but
   rather mediate the container that holds them.

   • Edit

4. 4 Posted by Tom on 19 Apr, 2010 01:02 PM

   

   Firstly congratulations on robot legs for solving this issue ive been using various way of doing this for years and the robot legs implementation beats them all.

   As joel says you need to subclass your button for the injector that can be as simple as this

   public class PlayButton extends Button{
   

       public function PlayButton()
       {
           super();
       }
   

   }

   but when you map it you can map it to the super class as a Button so your mediator dosn't care which button it mediates just that its a button

   mediatorMap.mapView(PlayButton,PlayButtonMediator,Button);

   this dosn't break any OOP rules as that button "is a" play button in you app and yes you will end up with some skinny classes but that's a small price to pay. You will see people doing the same thing with signals.

   • Edit

5. 5 Posted by Flex Incubator on 08 Oct, 2010 02:44 PM

   

   Hello.
   I need some clarification on the same topic.
   Let's say I have CustomColorPicker component which extends Flex ColorPicker. I have several instances of CustomColorPicker in my app (in different UI components, so they are not connected in some container). All instances of CustomColorPicker has the same input data (they uses the same color set), so in this case if I have only one CustomColorPickerMediator, it will be enough. But the thing is that each instance of CustomColorPicker updates different Models. So, taking into account comments in this post, I assume that I need to create subclasses of CustomColorPicker, and add Mediator to each subclass. Well, actually this is one of my question, does it mean that to use this framework we need to make new subclasses instead of instantiating? If not, then several simple examples will help.
   Well, maybe my own case will be such an example. So, we still have several instances of CustomColorPicker and one CustomColorPickerMediator. As i understand, teh Mediator will listen to the events of all instances. But I need to distinguish them in some way. What if use instance's id for this purpose. The event handler function in Mediator will then call some Controller and pass target id with event to it. Then the controller will be able to trigger changes in corresponding Model. Will all this make sense? I am new to Robotlegs and MVC, so maybe I am not taking into account some basic rules.

   Thanks for help.
   Ilya.

   • Edit

6. Support Staff 6 Posted by Stray on 08 Oct, 2010 03:18 PM

   

   As Joel says above, the best technique is to wrap them in a custom class.

   Then mediate them separately. If you want them to do different things, you probably need different classes to do it!

   Or - if you want each colour picker to update a different model, then you could use the colour picker id, pass this on your event, and wire it to a command which contains the logic to decide which model to update.

   Which I think is what you're describing?

   Personally, I prefer to subclass or wrap my components. But the ID approach is valid, just more prone to run-time errors.

   • Edit

7. 7 Posted by Flex Incubator on 08 Oct, 2010 03:30 PM

   

   Hello.
   Thanks for reply.

   Personally, I prefer to subclass or wrap my components.

   Yes, but how it all will correlates with reusing classes If we create new subclasses every time when we need a little bit different results (instead of creating new instances)? Actually, in my case all instances do absolutely the same job (sends color value), but the result should be different. So, I still think that sending id will be better approach in my case, won't it?

   But the ID approach is valid, just more prone to run-time errors.

   Could you please make some possible example of such run-time errors, so I will better understand possible drawbacks.

   Ilya

   • Edit

8. 8 Posted by Stray on 08 Oct, 2010 03:39 PM

   

   Hi there,

   the run time errors will simply be that you've got your logic wrong.

   For example - you copied and pasted the switch statement and forgot to change the ID, or wired it to the wrong Model.

   With strong typing the compiler can help you find these sorts of errors. Relying on strings/ IDs to tape your logic together makes it easy for the component to be updating the wrong model - so you'll spend time debugging.

   In your case, yes, it does sound like the ID approach will be OK.

   With something like a ComboBox, you can wrap the ComboBox in a class that then provides strong typing for the ComboBox contents, and that adds compile time checking that wouldn't be there otherwise.

   Stray

   • Edit

9. Support Staff 9 Posted by Shaun Smith on 08 Oct, 2010 03:51 PM

   

   It's very unlikely that one would bind a mediator to a color picker. Why? Because it's very unlikely that a color picker would need to communicate directly with an "application". A color picker's job is to select a color value and pass that value somewhere. That "somewhere" is probably not your application. More likely, that "somewhere" is a form, and it is the form that would be mediated.

   • Edit

10. 10 Posted by Flex Incubator on 08 Oct, 2010 04:10 PM

    

    A color picker's job is to select a color value and pass that value somewhere.

    Well, yes. But as I understand we need Mediator for communication between view component with other parts of the app (as well as with other view components). So, if this colorpicker is in one UI components, and "somewhere" is in another - why we do not need Mediator for colorpicker? How rest of the app will know about the colorpicker change event?

    Ilya

    • Edit

11. 11 Posted by Flex Incubator on 08 Oct, 2010 04:13 PM

    

    It's very unlikely that one would bind a mediator to a color picker. Why? Because it's very unlikely that a color picker would need to communicate directly with an "application".

    Well, what about print-online apps? Actually, though my initial question is abstract, it still has some references with my actual project. So, in print-online apps you can have several colorpickers, and they will do communicate with the app, because they will change Model(s). Or did I miss something?

    • Edit

12. 12 Posted by Flex Incubator on 08 Oct, 2010 04:22 PM

    

    I have realized that I still have to have different subclasses - though all my color pickers will really have the same input data (color set), but they also need to have independent selected color value, so i have to mediate them separately. anyway, despite i was wrong about my concrete case, i am still interested in my other questions - because actually i prefer to understand the whole logic, and not only concrete cases.
    Ilya

    • Edit

13. 13 Posted by Enrique on 02 Nov, 2010 09:20 PM

    

    And is not possible to map the mediator to a specific view's instance?
    Like Injector.mapValue maybe...

    • Edit

14. Stray closed this discussion on 10 Feb, 2011 06:04 PM.