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: Proxies, VO and a classic tree structure  (Read 13212 times)
Thomas B.
Jr. Member
**
Posts: 10


View Profile Email
« on: February 08, 2008, 10:14:28 »

Hello,

I am a beginner with the PureMVC framework, and I don't exactly know how to translate my data model in Proxies and VO... I'd like to manipulate a tree data structure, where every Node :
- is associated to an object (to store data),
- owns a list of all its children (an ArrayCollection of Node).
It must be something like this :

Node.as
public class Node
{
   private var _name:String;
   private var _object:Object;
   private var _children:ArrayCollection; // list of Node
   
   public function Node(name:String, object:Object):void{
      this._name = name;
      this._object = object;
      this._children = new ArrayCollection();
   }
   // getters & setters ...
}

Is it the right way to do, if I :
- create a VO with the code of the Node.as class,
- create a NodeProxy for every new Node (which means that Proxies are dynamically created, and identified by a unique name that could be their associated Node's name),
- put methods like 'calculateDepth', 'getAllDescendants', or all the classic tree-manipulation operations, in the Proxy ?

Or maybe have I misunderstood something ?

And : would it be a problem if I decide to not use VO, but put Node's properties directly in the Proxy ?

Thank you very much for your help.

Thomas

PS : I apologize for the poor quality of my english...
Logged
Rhysyngsun
Courseware Beta
Sr. Member
***
Posts: 51

Nathan Levesque

 - rhysyngsun@gmail.com  - rhysyngsun
View Profile WWW Email
« Reply #1 on: February 08, 2008, 01:05:53 »

I think you've pretty much got it, the only thing I would do differently, is instead of creating a NodeProxy for every Node, create a single NodeProxy that keeps track of a collection of all nodes. This will make it easier to find nodes, since you would loop through the collection instead of through Proxies.

You would probably also want a reference to the node's parent. Root nodes would have the parent property set to null.

Also, you would want to approach this differently if you're dealing with something like a database.
Logged

Thomas B.
Jr. Member
**
Posts: 10


View Profile Email
« Reply #2 on: February 08, 2008, 04:06:05 »

Thank you very much for your answer, that implies another question...
Does the single NodeProxy manage all the Node objects of the application, or do we have one NodeProxy for every tree that has been built ?
For example... Let's assume that users can create a new tree by selecting and copying a node in a tree structure (the copied node's _parent attribute is then set to null, because it becomes a new root). We now have a second tree, which is a subset of the first one. Can it claim to have its own NodeProxy ?
So, in such a case, which granularity for the Proxies creation policy ?

Thank you, in advance.
Logged
Rhysyngsun
Courseware Beta
Sr. Member
***
Posts: 51

Nathan Levesque

 - rhysyngsun@gmail.com  - rhysyngsun
View Profile WWW Email
« Reply #3 on: February 08, 2008, 07:28:42 »

You could go with either option.

If you chose to put everything under one Proxy, you would need to keep track of each tree. You could keep track of tress based on the value of _parent. Of course, you need to beware of Nodes accidentally being assigned null.

If you go with a Proxy per tree, you'll need to register each of these with the facade, remove them when you no longer need them, and have each instance return a unique value for the getProxyName function since this is how PureMVC identifies unique Proxy instances. This option has the benefit of keeping data access very narrow. Also, if you're looking for a specific tree, you'll potentially have to search through every proxy to find it.

I would go with the single Proxy option, mostly because all the data is in one place, and all you have to manage is the Node collection.
Logged

Thomas B.
Jr. Member
**
Posts: 10


View Profile Email
« Reply #4 on: February 09, 2008, 12:58:39 »

OK, thank you. The choice seems clear for me now.

But something still surprises me.
If all the data are stored into a single collection, a classic NodeProxy method like 'suppressNode' (which plugs the children of a node to its parent, disconnect it, and then, suppress it), would be invoked with :

aNodeProxy.suppressNode(noteToSuppress);
instead of something like :
noteToSuppress.suppressNode();

Hum. Maybe my questions could seem stupid... but :

1. The use of a single Proxy to keep track of data seems to be a 'distortion' of the Object Oriented way of programming... ???
2. And more generally, when we start a PureMVC local app and have to translate existing classes, do we always put attributes in VOs and methods in Proxies ?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: February 09, 2008, 12:15:28 »

Thomas,

1) There is no problem with having a Proxy around each object in a tree. Its merely a question of the granularity your implementation requires, and the collaborations you set up between those Proxies.

For instance, in the CodePeek application, examine the AbstractXMLDatabaseProxy (coming soon to a repository near you as a reusable utility) and its concrete subclasses.

The idea is that the abstract proxy provides the functionality to create and persist arbitrary XML trees. There is a parse method that it calls when the database has been read or created. That method is used in the concrete subclasses to snap twigs off the XML tree and feed them to new Proxies to tend each region. For instance the CodePeekPrefsProxy reads the preferences xml database, and creates a new WindowMetricsProxy, passing it the WindowMetrics element of the XML.

There could be any number of different preference elements, for instance ColorScheme. Then there would be a ColorSchemeProxy that created for that element. But they're holding references to parts of the big tree. Modifications to the data held by the WindowMetricsProxy updates the XML in the CodePeekPrefsProxy by reference..

2) Value Objects should be just that, carriers for data. Proxies should generally have the methods that massage that data, translate it or simply expose it to the app.

Hope this helps,
-=Cliff>
Logged
Thomas B.
Jr. Member
**
Posts: 10


View Profile Email
« Reply #6 on: February 10, 2008, 12:11:39 »

1. Thanks Cliff, I don't need to worry any more with the creation of hundreds of proxies... The lack of PureMVC examples which use this kind of practices made me wonder whether it could be an "acceptable" method.

2. In fact, a close colleague, with a strong 'classic' C++ background, was a bit reticent to split attributes and methods between two different classes. As we are working on a very big local app (neither network nor database), I'd like to be 100% sure to understand and master the underlying logic of PureMVC model organisation (whose examples focus on internet apps, with DB).

Thanks again, for the time you devoted to answer, and for the clarity of your explanations.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: February 10, 2008, 02:57:31 »

Thomas,

1) The appropriate granularity will make itself apparent pretty quickly once you get a few apps under your belt.

2) The main reason for only having attributes on a value object is that it is intended fo r shuttling data across tiers of an application.

That includes across client and server tiers. When marshaling and unmarshaling an object into a transfer format like XML, you can only send values. The methods wont go, or necessarily even make sense on the other side.

For instance on the server side you might want a method that takes a database row and populates the object. But on the client side, that wouldn't be needed. The obverse may also be true, there may be methods that it would be handy to have on the client but not on the server.

So your classes that are meant to be mirror images of each other end up with different methods based on which side they're on. Some folks have no problem with that, but personally I see it as a little messy. Easy enough to have those methods live on an object whose job it is to create or maintain the Value Object. Its just a matter of where the responsibility lies.

Consider when you find yourself writing a PureMVC Flex client to talk to a PureMVC Java backend.

Since they only have the responsibility of carrying data the AS3 and Java EmployeeVO classes are exactly the same, except language syntax. This makes their creation tractable to middleware code-generation.

The EmployeeProxy on the Server side deals with EmployeeVOs, but its work is primarily taking database rows and populating the VO.

The EmployeeProxy on the Client side, deals with the same VO class (marshaled from Java to AS3) and deals with sending EmployeeVOs back and forth across the line to a service.

Make sense?

-=Cliff>
Logged
Thomas B.
Jr. Member
**
Posts: 10


View Profile Email
« Reply #8 on: February 11, 2008, 04:51:59 »

The role of Proxies / VO in such a Client/Server architecture is now perfectly clear to me.

But I must admit that I'm a bit desoritentated if we now consider the Data Model of a RDA with only local data, like a multimedia creation tool or a classic single player game (data are destined to stay 'in' the app, on the local drive; no share, no distant access, no XML marshalling, etc.).

For example, let's assume the case of an audio segmenting and annotation tool. In the Data Model, we'll have something like an 'AudioSegment.as'. These sound fragments can be annotated, played, stopped, associated to other objects (pictures, lists of KeyWords, etc.)...
We have AS objects that has been designed for previous apps. For exemple, there is something like :
:
public class AudioSegment
{
    private var _sound:Sound;
    private var _annotations:ArrayCollection; // Collection of various objects of the Data Model
    (...)

    public function AudioSegment(url:URLRequest){
        this._sound.load(url);
        this._sound.addEventListener(Event.COMPLETE ...
        (...)
    }

    function play / stop (...)
    function getAnnotationsList (...)

    (...)
}
Where do we have to put instance methods ? I'm afraid I'm not able to properly understand how will the PureMVC Data Model look like...

Your answer will be more than precious to me...

Thanks, in advance.
Logged
Pages: [1]
Print