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: Data Binding Vs. Notification  (Read 3671 times)
hang
Newbie
*
Posts: 4


View Profile Email
« on: November 09, 2008, 03:08:06 »

Is the use of Flex's data binding something that's encouraged or discouraged?  It's quite convenient to use data binding for simple fields so that when one UI updates the data, all the other UI elements are updated as well.  This, however, seems to tie my code closer to Flex than what would be necessary.  I can see how I can accomplish the same thing with notifications but it can easily get out of control if everytime a field or variable is updated I have to send out a notification.  While I appreciate how PureMVC is not necessarily tied into Flex, the reality of my situation is that my code is tied into Flex and it would be silly for me to not use what is already there.

What are people's opinion on this? 
Logged
hang
Newbie
*
Posts: 4


View Profile Email
« Reply #1 on: November 09, 2008, 03:48:41 »

Well, I should have searched more.  This exact question has been answered: http://forums.puremvc.org/index.php?topic=60.0
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: November 09, 2008, 03:50:26 »

Data. Binding is great for wiring inside the black box of a view component. As you mentioned, to fill and collect values in a form.

But you want to bind to an object local to the view component rather than have binding expressions reacing back into the model tier to get the data.

One easy way of handling this is to have a value object that shuttles the data across tiers.

So the model tier retrieves the data, alerts the view and controller tiers by notification. The VO can be passed in the note or retrieved by the recipient. For instance a mediator might be interested, take the vo and set it on a public property of its view component.

Then inside the view component might be marked bindable and have a form getting its data from that vo. And reverse binding tags can also be setup changes to the field update the vo automatically.

Binding expressions are also great inside the view component for things like enabling components conditionally based upon internal state. Like only enabling a button when password is not null and password equals confirmPassword.

This is the stuff that belongs in a view component not in the mediator. It is nitty-gritty, down and dirty, sleeves up and more coffee brewing view implementation. If you migrate the app to another platform this is the part that will absolutely have to be reimplemented, so make it a black box with clear behavioral requirements and adapt that to your more abstract framework based apparatus.

The PureMVC part can port easily, but you have to live with your ui toolkit, but by feeding view components data and then leaving it up to the component what to do with ita mediator will insulate the rest of the architecture from foibles of the view implementation.
Have a look at the Flex EmployeeAdmin demo for examples of binding inside custom components.

Then for fun have a look at the python version which uses wxPyhon ui widgets.

-=Cliff>
Logged
Pages: [1]
Print