Re: [Boost-users] Editable XML Serialization

Subject: Re: [Boost-users] Editable XML Serialization
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-09-15 15:49:40

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