views:

93

answers:

2

I am trying to serialize an extended UIComponent (com.esri.ags.layers.GraphicsLayer) to send and store in a MSSQL Server database using WebOrb.

Apparently, these types of objects aren't meant to be serialized, and I haven't had much serializing/deserializing using the flash byteArray. I have also tried several other libraries(FlexXB,asx3m,JSONLite,as3corelib) with other formats (xml, json) with no luck.

Before I write some ugly-ass function, I am hoping someone may know how to do this already. Any thoughts/suggestions would be greatly appreciated.

A: 

One simple way to get what you're looking for would be to override the toString() method of your component class and have it return JSON or XML (whatever you like). To complement the toString() method, you would probably need a static method in your component class to deserialize the json/xml representation back into an object.

Apparently, these types of objects aren't meant to be serialized, and I haven't had much serializing/deserializing using the flash byteArray

A ByteArray would probably not be the best fit for a UIComponent, save for bitmaps, loaded SWF files and such (altho I have seen ByteArrays used for such things before).

If you need to reliably serialize your components, you're probably better off writing your own serialization/deserialization methods. The most appropriate way to do this would be by creating a base component (one that inherits from UIComponent) that offers these serialization methods and have each inheriting class override it with its additional properties. Finally, each extending class should call the super() method to get the serialized properties of the base class.

Sounds complex, but this is fairly simple and fairly common (In Cocoa, for example).

Lior Cohen
A: 

Hello,

I would suggest a custom serialization technique. It gives your complete control over the xml being produced/consumed especially in this case where you want to process UIComponents (they are not very serialize-friendly). FlexXB offers entry points for custom serialization in the form of a interface IXmlSerializable needing to be implemented by the target.

Another idea, which I personally favor :D, would be to have a model view approach. You would create a hierarchy of objects representing the model of your application. The views would then be only part of the display layer. Each view would accept an object of a specific type as data and would render the information accordingly. Adding/removing views would then translate into adding/removing model objects. Thus you won't care about serialization in the display views and you can implement it in the model objects making them perfect candidates for automated serialization (you can make them byteArray or XML or whichever format to store them). Also, you will be free to change the display views however you want. It is a fair amount of work but I believe it will pay off in time.

Good luck,

Alex

Alex Ciobanu