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: Why getData() and getViewComponent() exists?  (Read 7895 times)
Deril
Full Member
***
Posts: 22


View Profile Email
« on: August 06, 2011, 09:44:22 »

Hi,

 I am looking to these Proxy and Mediator functions, and don't understand why they are there.

It looks like they should not be there at all... here is my reasoning:

Job of the Proxy - hide and represent data stuff.
Job of the Mediator - hide and represent view stuff.

 Then we create those we want to hide all access to them, and don't let anyone touch it.

 Now then you send data object is super constructor (or view) you automatically create 2 problems, that has no reason (I know of) to exist.

1 - you need to cast it.
 (why not just store in your custom proxy as variable and leave it at it?)

2 - you expose your data(or view) to any actor in application, then in fact you want to do opposite - hide it as much as possible in most cases.
 (in rare cases you actually need to get full data or view, but why not hide it by default, and just create getter function to return data(or view) then you need it?)

 What am I missing?

Thanks for your time.

PS : I guess that this little functions create extra confusion for PureMVC beginners, you start looking for deep meanings that doesn't exists, thinking why you should pass you data to super class.. and create that casting functions.. but without good knowledge of Framework you afraid not to...
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: August 08, 2011, 10:30:15 »

Job of the Proxy - hide and represent data stuff.
Job of the Mediator - hide and represent view stuff.
The Mediator yes. We want, as much as possible to keep all sorts of actors in the system from needing to know the view components because they are the most frequently refactored portions of a rich client.

The Proxy, not so much. The entire View and Controller apparatus has no other reason to exist than to allow the user to view, update and interact with the Model. It is therefore understandable that any part of those tiers may have their own reasons for needing direct access to the Model. Therefore, there is no good reason to use the Proxy to 'hide' the data unless there is an explicit reason for doing so.

At its simplest, the Proxy can be used as a lightweight wrapper for registering data objects of any type. In fact, to do this, you don't even have to extend the framework class. You can instantiate a Proxy instance (passing in a name for it on the constructor and the data), and register it with the Model. Now any other part of the application can retrieve that Proxy instance with the name you passed in.

From that humble wrapper, you can build a data manager of arbitrary complexity as needed. If you don't want the rest of your program accessing the data except through approved methods then don't set it on the data property. Instead, make a private or protected property on your class and use that.

-=Cliff>
Logged
Deril
Full Member
***
Posts: 22


View Profile Email
« Reply #2 on: August 09, 2011, 01:37:42 »

That's interesting...

 it looks like we have different ideas how framework should be used..  ;D

I will investigate your ideas... thanks.
Logged
Deril
Full Member
***
Posts: 22


View Profile Email
« Reply #3 on: August 09, 2011, 05:10:18 »

 In most cases I want to encapsulate data because I want to notify about data change by sending notification, and the best place to do it -function that changes data.

 In some cases it's not needed, and you could use proxy as "raw" data holder only.
That's there getData() could be used.

 I am checking my code to find those places.. but in vain :) maybe in the future...
Logged
Pages: [1]
Print