ThinkGeo.com    |     Documentation    |     Premium Support

Runtime Style edtior and serialising Styles

#1

Hi Guys,


Been working on a runtime style editor and kind of thought I'd try serialisation (excuse the quaint British Spelling) to save a style to XML via XmlSerializer just to see what comes out.


Everything I try results in XML errors with unexpected objects (such as GeoPen etc.), even after using CloneDeep()


Has anyone tried this or can anyone point me in the right direction?


Regards


John


 



#2

John, 
  
 I’m afraid we didn’t support serialization for GeoPen. We support it only for some simple types (like shapes(pointShape, Polygon,…), GeoColor,…) and not support it for relative complex ones. (We should have supported GeoPen as that’s simple). I’ve added to the tracking system and we will review the serialization for all the classes in the future. Sorry for the inconvenience now. 
  
 Thanks, 
  
 Ben

#3

Hi Ben, 
  
 Thanks for that, confirms what I thought. 
  
 We have "rolled our own" serialsation for the Style editor. 
  
 Regards 
  
 John

#4

John,  
  
 Yes, that might be the only workaround for now. Hope we can enable all the serialization soon and that will be very convenient. 
  
 Thanks, 
  
 Ben.

#5

John, 
  
   I want to clarify our serialization plans.  What will work right now for all of the objects is binary serialization.  The problems with the  built in serialization formatters is that they do not consider changes to the API over time.  If you serialize something and then in the next version we add a new property though we did not break compatibility the serialization will fail to re-hydrate the old object.  The binary and soap formatters serialization techniques in the .net framework were designed for temporary use like for remoteing, session state,  and other short term operations and not for storing state for long periods of time between possible class versions. 
  
   This is where WCF and data contracts enter the picture.  These were designed specifically for being able to version APIs over time and for longer term storage.  At the current moment we do not have data contracts on our objects however this is our goal over the next two quarters, we are not exactly sure when but it is on the short list.  WCF really is the best solution, we just need to get it in.  For the short term you can roll your own which wouldn’t be bad however I suggest you isolate your serialization into  maybe a static helper class so that when we implement WCF you have one central place to change if you want to start to leverage our implementation. 
  
 David

#6

Hi David, 
  
 Thanks for that.  Good to know that WCF is on the way. 
  
 We have already gone down the static helper route and also implemented sparse serialisation in a attempt to save only those properties that are not the default, this tends to keep the XML size down. 
  
 The overall objective is to be able to take a layer and stream all the syles out to a single XML file and read them back again.  Have it working for the default styles, the more challenging stuff will be to do the rest of the other styles that could be used. 
  
 Regards 
  
 John

#7

John, 
  
  Sounds like a solid plan.  I am looking forward to the WCF stuff myself as it is a popular request to serialize the map styles and layers.  The old serialization libraries from Microsoft sucked really bad but  the WFC data contracts are quite cool. 
  
 David

#8

Hi David,


Did this Serialization make it into the relased version yet ?  I see you talking about end 2009 ish.


WCD with data contracts would be really handy.


I'm looking for a way for users to be able to make style changes - and then to save these.  If there is a "supported" way of doing this - that would be great


Thanks



#9

James, 
  
 Thanks for your post. 
  
 I am sorry to say that the WCF serialization was not included in the last public release. The reason for this is that we found some problem which cannot be solved using Data Contract. We may try to go-around this by write our own serialization and deserialization logic, while, this probably is a very large project. 
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale 


#10

John, 
  
   One way that works right now is binary serialization however it can have issues if new APIs are added to the object.  The WCF data contracts were disappointing as they did not handle blind inherited classes well.  What we are going to end of having to do is all custom serialization.  As Yalel said it is a fairly large task to complete but we plan to have a bunch of classes support by the May release. 
  
 David