VO's and Binding in an Actionscript only project

[eco_bach]

Most of the examples I've seen are Flex only and make ample use of Binding, especially when populating VO's.

Can someone give me an example of using VO's in an Actionscript only project?

[eco_bach]

Another problem I have with the best practices example are the way the VO's are instantiated in the view components.
To me, this doesn't make sense and makes the views less portable.

Shouldn't knowledge of the VO's ONLY be held by proxys, commands and mediators?

I would suggest instead adding public getters to the view components for any properties the corresponding mediator wishes to grab and populating the VO's ONLY in  or via the proxys.

[Jason MacDonald]

Another problem I have with the best practices example are the way the VO's are instantiated in the view components.
To me, this doesn't make sense and makes the views less portable.

Shouldn't knowledge of the VO's ONLY be held by proxys, commands and mediators?

I would suggest instead adding public getters to the view components for any properties the corresponding mediator wishes to grab and populating the VO's ONLY in  or via the proxys.

This is how I use VO's as well. I don't like having my reusable components require additional files like VO Objects. I usually either have something (Mediator) set the VO values on the component or I have a generic parse function in the component that will take an object and test for the values it thinks it should have using Object.hasOwnProperty() and then extract the values and apply them

[puremvc]

Imagine you have 10 view components that all accept the same 5 pieces of data. If you don't let a view component know about the VO, then you have 10 mediators that must receive the notification and copy the values over from the VO to their view components. 10 places where you can drop the ball when you those components need 6 pieces of related data.

At the end of the day, a view component often needs a complex set of inputs. And exposing those as raw fields and having to have code that gets the values from a VO and sets them onto properties of the view component is fraught with problems. You add a new value to the VO, but you forget to add it to the transfer from VO to View Component code, and you wonder why the property doesn't show up in the View.

The Value Object pattern is meant to allow transfer of complex data across multiple tiers of an n-Tier system. By agreeing on the entity that the value object represents, all actors across the system can agree on the data structure.

And just because a view component takes a VO as a property does not hamper its portability.

Lets say you have a proprietary mapping system called Maporama that you've built for your company. And the company decides that some nifty navigation component you've cooked up could also be sold as a reusable component!

But your nav component takes a com.ultramegacorp.maporama.model.PositionVO! Do you tell the boss to forget all that extra income, it'll take you a forever to make the component reusable?

Nah.

1) Create a new library project MegaNav and refactor/move the component and the VO to that project.

:

com.ultramegacorp.maporama.model.PositionVO -> com.ultramegacorp.meganav.PositionVO
com.ultramegacorp.maporama.view.components.MegaNavComp -> com.ultramegacorp.meganav.MegaNavComp
Note the component packaging in the library doesn't have to reflect the MVC structure at all. End users may not care about MVC or the flavor you use. In this simple case we have a view component and a related data object, no need to force any more structure on the user than that.


2) Take the swc from the MegaNav library project and then put it in the libs folder of your original Maporama project.

3) Replace references to the PositionVO and MegaNavComp in your Maporama project.

Now your original project Maporama is just another user of your soon to be widely-used MegaNav component library. 

You'd have to do these three steps to extract the view component anyway if it is going to be resold, you're just moving the VO along with it.

As long as both are documented, then the end user of your component sees a single positionVO property of type PositionVO, and they see the values it carries. They use the component by instantiating a VO with the appropriate properties and passing it to the component in the same way the mediator does in your original app, but they are in no way tied to the implementation of your application. Nor do they need to use the MVC framework you've chosen.

-=Cliff>