Anne van Rossum wrote:
Dear list members,
I guess it's one of the hardest search terms around but I would like to know if there is any editable XML serialization provided by Boost or other C++ libraries. And I don't mean the kind of thing that requires you to go jumping around through trees, with iterators etc. I don't want to see any iterator!
I really iike the XML serialization method that boost::serialization provides:
//! Give boost serialization libraries access to private fields friend class boost::serialization::access;
//! Tell which private fields to serialize template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & boost::serialization::make_nvp("Phase", phase); ar & boost::serialization::make_nvp("Period", period); ar & boost::serialization::make_nvp("DutyCycle", dutycycle); }
Just adding this to a file, and then:
xml_out << boost::serialization::make_nvp("ApplicationConfig", config);
Or: xml_in >> boost::serialization::make_nvp("ApplicationConfig", config);
It's awesome! I don't need to care about descending trees, etc. However, the default serialization class does not allow for different orders of the XML tags, etc. It doesn't use the "ApplicationConfig" string, but just assumes that XML tag should be there if this read operation. If you change anything in the XML file, it is likely you will get a segfault, and you won't know what is causing the problem exactly.
It would be so great if there is something like this in which the XML files can actually be edited! I am almost sure that there should be something like that, but I can't find it.
A rich subject which comes up from time to time. Here are a few miscelleaneous observations. a) Most of the time what people want when they ask this question is xml_in >> my data structure for some arbitrarily defined structure. Of course after you become familiar with the library, it's easy to see that this is not possible. It's annoying to me how often this is stated as a failing of the library. b) It is possble to so some limited editing of xml (or other archives) but this would be an ad hoc procedure subject to errors. you might change a value here and there but the minute you change something tracked or add a value to a collection or whatever, you're not going to be able to keep things consistent. I guess you're familiar with this. I've thought about this alot. Here are some ideas that I thought about. a) create an xml_archive along with an xml schema which would be friendly with known xml editors. I thought about this alot an concluded that it would be too much like training an ant to train a flea. I don't think it would be possible to make a bunch of rules that an xml editor could follow and guarentee that that the resulting C++ data object would be correct. Even it were possible, one would likely have to add a bunch of "helper" information to get it right. It would be hard to use, easy to misuse, and a maintainence (and support) nightmare. So what I want to do is to make the following: edit_oarchive<widgets_library> edit_iarchive<widgets_library> The usage would be the following: edit_archive<mfc_widgets> ea ... ea << my_data // the data is rendered using the supplied widgets library. A // widgets library would exist for QT, MFC, WTL, and whatever. // // This archive class would map types to standard things like // int would be mapped to a labeled text box // list of ints would be mapped to list of integers // enum would be mapped to a drop down list // ... // the user would edit the widgets - like a dialog box and // hit OK. Then ea >> my_data which syncronizes my_data with the widgets. We actually made a working proof of concept a few years ago. I made the mfc version and someone else - forgot the name - sorry - made one for qt (I think). I concluded that it would require too much work to get it ready for prime time and that there were more pressing issues. There still are but maybe some day. The main think I liked about this is that a) it could be guarenteed to work - at least as much as the current library is. b) it would be maintainable and supportable. c) wouldn't be coupled with some external tool d) wouldn't be coupled with xml. Maybe someday someone will hire me to do this. It's not not trivial task. But I'm convinced that it is actually doable. Lately, there has been talk on the list about a GUI library. (Yes, it's about that time again). This task is much smaller and potentially much more immediately useful. Robert Ramey