Re: [libxml++] sax parser

[Christophe de Vienne <cdevienne alphacent com>]

Murray Cumming Comneon com a écrit :

> > From: libxmlplusplus-general-admin lists sourceforge net 
> >
> >
> > It is not meaningful to XML or machines, but it is often 
> > meaningful to HUMANS! If we are making a XML editing 
> > application--whatever it is--where people might be editing 
> > some of the XML by hand, mnay would prefer attributes remain 
> > in the order they originally wrote them for some reason. In 
> > HTML editors, this is sometimes called "roundtrip" where the 
> > tool attempts to preserve the integrity of the original HTML 
> > as much as possible.
> >    
>
> If libxml++ does not preserve the order, and libxml does, then I'm willing
> to consider this a bug.
>
>  

It looks like SaxParser does not preserve the order of attributes in 
start_element callback, since it uses an AttributeMap which is defined 
as std::map<std::string, std::string>.
Anywhere else it should be ok since we use directly libxml2 API.

The solution would be to use a std::vector< std::pair<std::string, 
std::string> > instead of a std::map<std::string, std::string>.
Loops on the container would be almost unchanged, but looking for an 
attribute by it's name would be a little more change :
attributes.find('name')
could becomes something like :

struct FirstIs {
   std::string const & s_;
   FirstIs(std::string const & s): s_(s) {}
   bool operator()(std::pair<std::string, std::string> const & v) { 
return v.first == s_; }
}

find_if( attribute.begin(), attribute.end(), FirstIs('name'))

We could eventually provide a helper to make it easy.
I think the overhead wouldn't be sensible unless we have dozens of 
attributes

Thoughts ?

Christophe