Model VO extending DisplayObject?

[honi]

Hello! I've been reading the forums for a while now and it's been of great help.
I've come to the following situation and don't know what would be the best way to solve it.
I'm aware of the model data / view component separation.
But in this case mi "data" is actually a bunch of visual properties for view elements.
These elements are added to a "World" component which has it's own mediator.
Elements don't have mediators.

So the thing is.. If I make an ElementVO holding all these visual props, I have to then copy them to the actual Element which is created by the World Mediator.

I think it would be better to just make the ElementVO the actual Element.
That way, in my ElementProxy, I create all the Element objects and assign there visual props (that's my data).
Then I could pass all the elements to the World Mediator which will add them to the World.

Is this wrong? Is there a better way to achieve this?

[puremvc]

Have an ElementVO property on the Element class. When the WorldMediator creates an Element, it should then set the element's elementVO property. Then internally, the Element can do whatever it needs to with the properties of the VO. This will minimize what the WorldMediator has to know about the Element, and the Model doesn't need to know anything about any view components.

-=Cliff>

[honi]

That brings me up another question:
Is it ok for viewComponents to use VOs?
Wouldn't that couple the viewComponent in some way to the puremvc framework?

Lets say you have an ImageViewer component with a function show() that recieves 2 parameters:
image:Bitmap, caption:String

If there's an ImageVO whith those 2 porperties, I could do:
imageViewer.show(imageVO);
or instead..
imageViewer.show(imageVO.image, imageVO.caption);
and that way decouple my ImageViewer class with that specific VO

Now I can use the ImageViewer in another proyect that uses another type of VO, say a ProductVO with properties like id, name, price and image. (the caption could be name + price)

[puremvc]

It won't couple the View Component to the framework to use a VO. The point of a VO is to have a common object that can shuttle data across all tiers of an app.

It's all about refactorability. If you want to reuse the View Component and VO outside the system, you can include the View Component and the VO in a SWC. Then anyone could use it, and there is no requirement to also use PureMVC.

For instance, you could have a MapView that takes a MapVO. Inside your app these might be packaged:

:

com.me.myapp.view.components.MapView
com.me.myapp.model.vo.MapVO
You can easily move those to a separate library project, create a swc and then drop that swc back into your application's libs folder. Remove the original classes from your app (since they're now coming out of the swc), and recompile. That was easy.

But for wider distribution and reuse, you might now want this library to have its own name and packaging instead of retaining the myapp package. And since it's no longer within a PureMVC context, you don't need the deep hierarchy, so you might refactor that as well to something like:

:

com.me.mymapwidget.MapView
com.me.mymapwidget.MapVO

Drop the swc back into your original app and change the references to the old packaging for this component and VO to their new shortened packages. Recompile. All's well.

Now you have refactored a View Component and its VO into a library that you can sell or give away and no one has to know anything about the PureMVC app it came from. And your app now uses it in the same way it would use any other third-party library.

So you can see that the refactoring steps to isolate the component and its VO dependency are straightforward.

This would not be the case if the View Component were relying on a Mediator or a Proxy, which would in turn require the PureMVC library and that the Mediator or Proxy be registered in a running PureMVC core...

-=Cliff>