This project is read-only.

Extending the Map.Xml project file

Sep 23, 2010 at 9:45 PM

I have question regarding the DotSpatial Serialization and the 'map.xml' file.

I'd like to re-use the built in DotSpatial serialization code for map layer symbology and for labels, but I also need to save additional information to the project file:

  • Which Apps or Plugins are enabled?
  • Database connection string
  • Plugin-specific and App-specific settings.

Is there an easy way to include this information in the built in DotSpatial 'map.xml' file? Also, with current changes in namespaces, is the data format of 'map.xml' backwards compatible?

Sep 23, 2010 at 10:44 PM

There is good news and bad news Jiri.  The good news is that extensibility is not an issue, and you have multiple options.  You can re-use the serialization code to serialize a new class by adding the [Serialize("PatternType")] tag and then using the XMLSerializer class to serialize it.  An option in the map case to make extended maps reasonably compatible with non-extended maps is to inherit from the MapFrame itself.  If you use inheritance to create your own kind of object (at least during the save and load events) then when you use the serialize method, you could add whatever properties you want.  Just be prepared for the extended content to be null in the case where it is not.  The real blow to the map files is that we store a lot of information about an object in the file.  If the namespace of the object changes (like it will with the refactoring I am introducing in DotSpatial) then the old maps will no longer find objects with the correct type.

Given that we are in the middle of introducing a formatting change that will break the old map-file compatibility, maybe it would be ok for us to just add those items to the MapFrame itself.  At least as an "IApplicationSettings" interface, which might have nothing on it and do nothing by default except be null.  Then in your program, you can put whatever you want on any kind of class that you want, as long as you implement IApplicationSettings, which you can do easily since it has nothing on it, then add any content you want to, and it will serialize correctly when you set the MapFrame's IApplicationSettings to be equal to your object.  Make sure you put it on the MapFrame (and not the Map control).  However, the trade-off for this power is that changing the namespace arrangement in your serializable object, or in any of the serializable settings objects from any of your plug-ins may result in members that can't be found.  We would need to alter the de-serialization code so that broken properties, or content for plug-ins that don't exist, are simply ignored, rather than throwing exceptions.  This would mean that even if you have saved application settings for PluginA, but PluginA no longer exists, it would just ignore it.




Sep 23, 2010 at 11:44 PM

Thanks for the info.

Extending MapFrame by adding a property of type 'IApplicationSettings' is a possible solution.