Hi,

We just released a new site: http://legendsofvalhalla.com

As usually we used PureMVC and as usually we loved doing it.  Thanks Cliff!

Best regards,
Sammi

Lead programmer @ gagarin.is

Hi,

The proxy could have just the ShapeDataVO. The ShapeDataVO has getters like:

- getAllShapes():Vector.<ShapeVO>
- getShapeByID():ShapeVO

The ShapeVO has a getter to return CoordinateVO's:

- getCoordinates():Vector.<CoordinateVO>

I would search the forums for "SmartVO"

Best,
Sammi

Thanks,

so as long as I don't have hundreds of views and hundreds of labels I just pass the whole vo to the views.  It simplifies things and then if a view suddenly requires a new label I don't have to modify the mediator to pass that label.  The mediator just passes the vo with all the labels in the application.

Best,
Sammi

Hi,

Sorry about the brain tease.  I didn't explain properly.

I think it might be more clear to see an example.  Here is a simplified version of my vo:

:

package site.model.vo
{
    public class LocalizedLabelsVO
    {
        protected var _labels : XML;
        public var language : String = "english";

        public function LocalizedLabelsVO( labels : XML )
        {
                _labels = labels;
        }

        public function getLabel( labelID:String ) : String
        {
                var label : String = _labels.(@id == labelID)[ language ];
        }
    }
}

Notice that this vo has a "language" property - not just the xml data that was passed into it's constructor.

Is there anything wrong with that?

The purpose of the smart vo is to hide the XML structure from the application and to provide typed access to the xml.  Having additional properties in the vo doesn't break that so I guess there is nothing wrong with this method.

When there is a LANGUAGE_SET notification a command updates the language property in the proxy's vo and interested mediators call translate() on their views passing along the vo from the proxy. Then the views can easily be translated.

Best,
Sammi

Hi,

I am using my home brewed method for view localization.  It is simple and quite effective but I am still thinking of ways to simplify and thought I would get other people's opinion on a particular aspect of my method.

To simplify things I am not talking about the localization of the content - but interface elements like button labels and such.

Here is the flow right now:

1)  I have an XML document with all labels
2)  I have a Proxy that loads them and turns them into a smart vo
3)  The smart vo has a method to return a label identified by an id like SAVE or CLOSE
4)  My mediators collect the labels required for their views and pass them to the views as dictionaries
5)  The views use the dictionary to update all labels.

I have been thinking of skipping step 4 and 5 and just throw the whole smart vo to the views for simplicity.

The problem with that approach is that all the views get ALL the labels.  So even a simple view like "LogoutView" that only needs one label would get the vo with maybe 100 labels.

What do you think?  Maybe for an application that has only few views this is ok but what if the app has a lot of views?  Could/should I find a way to pass just a reference to the vo?

Best,
Sammi

I was wondering if it is considered "dirty" to have the VO foster more than the XML passed in from the proxy?

In my current case I would for an example want to add a "language" property to my LocalizedLabelsProxy.  All my labels come from an XML document but the selected language does not.

I don't think there is anything wrong with it - but I have been proven wrong more than once

Best,
Sammi

Thank you.

I am creating VO's like crazy now and feeling good about it!

Best,
Sammi

Hi,

How stupid can I be?  I have been converting my code to use smart vo and thought I was doing ok.  My vo's have getters/setters for elements in the XML and the views have typed access to them.  But then....

Ooops - my getters are returning XMLList in many cases.  That can't be good because then the views have to know the structure of the xml - so the smart vo aren't really solving anything.

Should I go ahead an make vo's for each item in the XMLList and return them as vector or something to the view?  Seems a lot of work and a lot of VO's.

In one particular case I have a NavigationProxy where it's data is an xml document with all navigation items as well as some properties regarding the navigation.  The Proxy instantiates a NavigationVO that has getters to access the nodes and one is to actually get all the navigation nodes for a particular level for the view to iterate over and render.  Currently I am returning it as an XMLList

Should I have that getter return a vector of NavigationItemVO for an example?

Seems like I would be creating a lot of vo's.  Basically a vo for every type of node that I am currently return as lists.

Best,
Sammi

Super!

Thanks.

Hi,

I am looking into this Smart VO concept and I like it.  I have a few questions just to clarify things and it would be great if someone could share his experience/knowledge.

I usually have many Proxies that just have an XML document as data. Until now I have simply added getters and setters in the proxies to give PureMVC actors typed access to the xml.  I don't find it too bad but I do understand that a smart vo has benefits.  Especially for the views - I think.

Is it true that the main benefit is that the vo could be thrown at a view and the view then has typed access to the data?  Obviously the views have not had access to my getters/setters in the Proxies so code has been required to push the data into variables on the view - and to pull them back.

Since a VO isn't a core PureMVC actor it is fine to have the views import them and use and that simplifies the code...

... to push the data to the view
... to pull the data from the view again
... to have typed access to the xml doc

Am I right, almost right, wrong or even terribly wrong?

Best,
Sammi

Brilliant answer

So I will just have my proxies manage an XML object instead of a VO.

I would store each shape as an xml string in the database or simply store all the objects on the canvas in a single XML object.

The XML object could include the version number used to generate it so that any future versions of the app would know how to convert it to the latest format.

Best,
Sammi

I was thinking it must be a rather bad idea to just serialize the vo's or proxies because it would be very difficult to add properties to the vo's or proxies later on. 

Lets say that in the first 1.0 of the application a BoxVO has a properties a,b and c.  Then in version 1.1 I want to add property d.

After I add the d property, deserialization of the BoxVOs from the database would then fail because of the mismatch. The objects don't match.

Am I right? Or am I misunderstanding the process if serialization and deserialization?

Best,
Sammi

Hi,

I am about to start a new PureMVC application and although my question really has nothing to do with PureMVC I am sure many of you have already encountered and solved a situation like mine.

The application is a drawing app. The user has a canvas to draw shapes onto.  The shapes have multiple updateable properties like fill color, line thickness, z-order and so on.  The user must be able to save and load drawings and my question is about how it is best to approach that.

I have made similar stuff in the past and then I have saved each shape's properties into the database making it fairly easy to redraw them when loaded.

I don't want to do that again if things like "class serialization" and/or "byteArrays" would somehow be more appropriate.

How would you save what has been drawn to the canvas? 

In PureMVC I will most likely have a VO for each shape on the canvas.  Would you serialize the value  objects and save them into the database as strings?  What happens if ( and when ) I need to alter the value objects? 

I hope someone here has some experience in this area and would be willing to guide me in the right direction.

Best,
Sammi

Yes, I was thinking about that too.  It makes sense to keep reusable view components out of the project specific package structure, just like any third party reusable classes.

Best,
Sammi

Roger that.

I like this way of organizing things.

Best,
Sammi