PureMVC Architects Lounge

Hi all,

I have recently discovered that it's ok to make use of databinding between model and view (through the use of a mediator ofcourse) when you're using ArrayCollections.
See this post ( http://forums.puremvc.org/index.php?topic=81.0 ).

Now I was wondering, if it's ok to do this with ArrayCollections why couldn't I also do this with ValueObjects or any object for that matter?
I noticed in alot of demo's that VO's get send back and forth between view and model to update the data but why not make use of databinding? It would make life so much easier!

I would really like to hear some thoughts on this and if this would be considered bad practice.

Data binding within a MXML component is fine. But what you don't want is for a view component to use a binding expression that retrieves the Proxy to bind to its VO. That's something you see often in Cairngorm apps. Then your view component can never be reused without that model being there, and all the apparatus that puts it there.

So what you do is deliver the data to the view component by way of its Mediator. Then inside the component itself, the property that the Mediator sets is what the rest of the component binds to.

The component should know nothing of the system it is connected to, but rather expose an API of properties, methods and events so that the Mediator can communicate bidirectionally with it, while not needing to know much about the view component's internal implementation.

-=Cliff>

No, I get that part.

What you're saying is that the mediator should pass the VO from the model to the view component because that way the view component doesn't have to know about the rest of the system.

Now when you do this with an ArrayCollection and you pass the data in the mediator (from the proxy to the view component), you're binding them so when you change the ArrayCollection (e.g. drag & drop to change the order of the collection, or updating the properties of the VO's in the collection) in the view it also changes in the model.
In this thread ( http://forums.puremvc.org/index.php?topic=81.0 ) you say that normally you want this behavior (databinding) because it saves you a lot of time and trouble.

What I want to know is if you can apply this same behavior to VO's as well.
So the proxy returns a VO and the view component has it's own VO where it's properties are binded to. Now the mediator links/passes the proxy VO to the component VO.
When for example a text component changes in the view it also changes in the proxy as well.

Is this acceptable behavior? Or should I not be doing this?

If you are working with a reference, the Proxy's version of the object will change as well, yes. The proxy will need tos set event listeners on the ArrayCollection if it needs to *respond* to that change, of course.

Do you want this? Its up to you and your app. You may only want the data to change if you confirm your changes, and discarding should leave it the way it was, in which case a clone of the VO not a ref is what you want. And overriding the ref inside the component with the newly populated VO won't change anything at the Proxy unless you've stuffed it ito a reference to an ArrayCollection held by the Proxy.

Have a look at how this is handled in the EmployeeAdmin demo.

-=Cliff>   

I'm not quite shure what you mean with this sentence: "And overriding the ref inside the component with the newly populated VO won't change anything at the Proxy unless you've stuffed it ito a reference to an ArrayCollection held by the Proxy.".

See I assumed that you couldn't/shouldn't pass a reference of a VO from the proxy to the view component and, through binding to say a textinput, have it automagically be updated in the proxy because VO's DON'T fire off events that their properties have been updated like ArrayCollections do.

But it turns out that they actually DO fire off an event (that you can respond to in the proxy) that their properties have been changed!

Making the VO class (or just some properties) [Bindable] makes them implement IEventDispatcher. You can then add an eventlistener to them and respond by sending a notification that they have changed.

To take your example of discarding the change, you wouldn't even need to make a clone.
Since they fire off an event (PropertyChangeEvent) that they have been updated (including the old and new values) you could also choose to "reset" the VO to it's previous values by just setting the new value of the VO property to the old value (these values are sent with the event).
This way you can make a VO behave just like an ArrayCollection and have everything update automagically.

My point is, is that I don't see why you would have to send a VO (by having a mediator respond to an event from the view component)
from the view component to the proxy, to update the proxy with new values.

Is this an acceptable way to update the proxy?

Yes. That is - for the VO to be made bindable and for the Proxy to listen to it for property changes.

-=Cliff>

Thank you Cliff!

This will save me a lot of work from now on.

I just find it strange though that I don't see this way of data binding of VO's in any of the demo's.
In the past I was sending VO's back and forth like crazy.
But this method is a lot more efficient.

Anyway thanks again for your insights and keep up the good work!

The reason this way isn't advocated or shown in any demos is that it relies on very Flex-specific functionality.

Now there's nothing wrong with that until you're trying to port one of these demos (or worse, a legacy app) to say, Python or Java which may not have that same functionality availble. That means rather than a simple migration, you're re-architecting core functionality of your app.

Therefore demos and stated best practices here take a conservative approach when it comes to reliance on platform specific magic.

Don't get me wrong, Flex rules, but when and if you find yourself porting a PureMVC Flex app to SilverLight, for instance, you'll be way happier if you went with platform neutral choices for your key functionality.

-=Cliff>

Makes sense.

It's just a shame though that many people starting out with PureMVC and Flex, and who will probably just stick to these, will do it the "save" way and keep doing this for a long time until one day they realize that they could have been doing it the "magical" way.

Nah, maybe I'm just slow.  :P

I was actually quite shocked when I realized this "new" way of doing things.
Here I was thinking data binding is forbidden and I better just stick to best practices.
Quite funny though when your eyes finally open up  ;D

Hope this thread can help some other poor chap to see the light ;)

All of my VOs extend EventDispatcher and I make liberal use of databinding. This is because the chances of me porting anything to Silverlight are null (famous last words?). ^^

It sounds like your life just got that much easier.

It sure did  ;D

Could someone please post and example of extending the VO to show it can by bound between the view and the proxy?

Thanks

Don't bind to the Proxy from a View Component.  It makes your view component less portable, and it breaks the MVC concept in half and stomps up and down on the pieces. We're attempting to separate those tiers to eliminate the spaghetti code. That's the point of MVC.

There's no problem with making properties of a VO that the Proxy holds bindable however. Just add the [Bindable] metadata tag to the class or a property. The VO does not have to extend EventDispatcher, all the 'magic' is added by the [Bindable] tag.

So a Proxy might get the data from a service and toss it to the Mediator who sets it on the view component. The view component may then bind to the values and if there are other view components who are bound to the same properties of the same object, they will 'magically' be updated.

Check out the Employee Admin demo for an example of this in the UserVO
http://trac.puremvc.org/Demo_AS3_Flex_EmployeeAdmin

If you debug, you will get a message about not being able to bind to the 'givenName' property when you click on one of the items in the list, but that is because it is a getter without a corresponding setter (a read only property). All the standard properties are bindable.

-=Cliff>

Gotcha.  I think I am doing what you said.  My proxy has a VO that is bindable.  The mediator sets the components locale VO copy to the proxy's VO.  However, looking at the EmployeeAdmin demo I see that a new UserVO is created and sent back on Submit().  I was thinking that the approach described in this topic would eliminate the need to send VO's back and forth because we would be working with the same copy.  This may be my inexperience showing but I thought that the bindable communication was both ways. 
So that if I have this...

[Bindable] public var currentProject:ProjectVO = new ProjectVO;
<mx:TextInput id="pd_projectCode" text="{currentProject.projectCode}"/>

it would mean that and changes to the pd_projectCode.text are also reflected on the currentProject.projectCode.  My view component has alot of fields so was trying to prevent having to get assign all the component values to my VO to be sent back to the proxy.

Is this possible?

Did some more research last night and I think what I need to do is as stated in this post.  http://forums.puremvc.org/index.php?topic=1365.0

By creating a custom view component that comes with its built in VO? Also, this would probably help some when I have to validate all my fields too.  Well... we'll see how it works out.

However, looking at the EmployeeAdmin demo I see that a new UserVO is created and sent back on Submit().  I was thinking that the approach described in this topic would eliminate the need to send VO's back and forth because we would be working with the same copy.  

If you revisit that application (actually run it and click an employee in the grid, populating the form, and then edit and submit your changes), you'll realize that you don't want to be editing the original VO. Otherwise, abandoning your changes would NOT be as simple as clicking Cancel instead of Submit.

Instead, we want to populate the form, edit it locally in the form without our changes disturbing the rest of the system, and send back a new one if we like our changes.

If you were working with the same object held in the Proxy, then as you modify your employee in the form every keystroke could cause your changes to be reflected in the data grid (if you were using two way binding (which we're not in this demo but often do - see my answer to your next question below).

What happens when you click cancel? Well, if you're editing the only known good copy, you have to have a backup copy to replace the edited copy you're abandoning. So either way, you're working with two copies. It's just that the latter way doesn't make sense because you don't want your changes making it out of the form until you've ok'd them.

I thought that the bindable communication was both ways. So that if I have this...

[Bindable] public var currentProject:ProjectVO = new ProjectVO;
<mx:TextInput id="pd_projectCode" text="{currentProject.projectCode}"/>

...it would mean that and changes to the pd_projectCode.text are also reflected on the currentProject.projectCode.  My view component has alot of fields so was trying to prevent having to get assign all the component values to my VO to be sent back to the proxy.

Nope. That's one way binding from the VO to the form. To get binding back from the form to the VO, you need to additionally use a binding tag that watches the changes on the form and updates the VO.

[Bindable] public var currentProject:ProjectVO = new ProjectVO;
...
<mx:Binding source="pd_projectCode.text" destination="currentProject"/>
<mx:TextInput id="pd_projectCode" text="{currentProject.projectCode}"/>
-=Cliff>

Did some more research last night and I think what I need to do is as stated in this post.  http://forums.puremvc.org/index.php?topic=1365.0

By creating a custom view component that comes with its built in VO?

That thread (as far as I can tell) only talks about having a VO that can be repackaged into a library with a view component that uses it. I don't see that it changes anything with regard to how you deal with that VO in the application.

-=Cliff>