PureMVC Architects Lounge

I am having a reference to a viewComponent class ( say A_View )  inside a mediator ( SystemMediator ) . So naturally SystemMediator can use the reference of this viewcomponent to access all the member functions of A_View.  So, is this ok ? I am doubtful ? Should i use sendNotification to access the A_Mediator and then access the member function of A_View. But why should i adopt this roundabout way when reference is present in SystemMediator.

Thanks.
V.

Hi V
Your question is not clear enough.
Naturally, in case your mediator has a reference to a view component, it should access the component's API(not the components children).
But I am not sure that this is what you are asking.
Can you elaborate?

I am having a reference to a viewComponent class ( say A_View )  inside a mediator ( SystemMediator )

Why is the mediator not called A_ViewMediator instead of SystemMediator? Generally the mediator is named according to the component it tends.

So naturally SystemMediator can use the reference of this viewcomponent to access all the member functions of A_View.  So, is this ok ? I am doubtful ?

If SystemMediator's reference to A_View is by having a reference to A_View's parent in the display list, then no, you should not manipulate A_View from SystemMediator, but should instead, either:

A) Have A_View's parent in the display list encapsulate interaction with A_View (i.e. expose a method that SystemMediator can call and have that method do the interaction with A_View)
B) Mediate A_View and then A_View's mediator can make calls to A_View's methods and set its properties.

Should i use sendNotification to access the A_Mediator and then access the member function of A_View.

I assume you mean should another actor, such as a command, send a notification to SystemMediator who'll respond by interacting with A_View. Yes, this is the appropriate way of interacting with A_View from elsewhere in the app.

But why should i adopt this roundabout way when reference is present in SystemMediator./quote]
Because it isolates the knowledge of A_View to a single actor - its mediator. This is an example of the loose-coupling we desire in OOP. If you spread knowledge of a component around the system, it makes it difficult to replace that component or change its API without having to refactor all the classes that know it.

-=Cliff>

Hi Cliff

A) Have A_View's parent in the display list encapsulate interaction with A_View (i.e. expose a method that SystemMediator can call and have that method do the interaction with A_View)
B) Mediate A_View and then A_View's mediator can make calls to A_View's methods and set its properties.

Can you explain what do you mean in B?
What do you mean by "mediate A_View"?
As I see it, A_View's mediator always can make calls to A_View's methods.
I guess I'm saying that I don't see the difference between A and B.

Eli

here is my query, i have depicted it here :

(http://img94.imageshack.us/img94/9910/queryq.jpg)


SystemView, is actually a layer above all other layers ( movieclips), that handles the task ( similar to an OS, like handling popups, showing effects, messages etc )

MyView, is some component below the SystemView movieclip .

My query is, if it is legal to call MyView member function to call directly from SystemMediator ? Or there is another correct way of doing this.

Thanks
V.

My query is, if it is legal to call MyView member function to call directly from SystemMediator ? Or there is another correct way of doing this.

No. As mentioned previously in this thread, the advice is:

If SystemMediator's reference to A_View is by having a reference to A_View's parent in the display list, then no, you should not manipulate A_View from SystemMediator, but should instead, either:

A) Have A_View's parent in the display list encapsulate interaction with A_View (i.e. expose a method that SystemMediator can call and have that method do the interaction with A_View)
B) Mediate A_View and then A_View's mediator can make calls to A_View's methods and set its properties.