Added CDATA support to the toString()

[nyurik]

For complex values that contain '<', '>', or '&',
support CDATA construct if opts.cdata is true.

[amtrack]

👍

[nyurik]

@nfarina, @wotzisname - is there anything wrong with this PR?

[nfarina]

Sorry it took me so long to review this!

I think this looks great for the most part. I like the new escapeValue function rather than the (probably misused) encodeURIComponent.

It looks like CDATA tags are output "automatically" when requested in options based on the presence of characters like <, > in the value. Would it be more correct to look at the isValCdata flag on XmlElement instead? That way we can preserve the format of the original XML structure.

[nyurik]

@nfarina thanks for the review. For my usecase, I need to force various elements to cdata (silly mapnik lib has weird xml parsing rules). But for general use, sure, it might be good to allow both.

[nfarina]

You could control which elements are exported as CDATA by setting myElement.isValCdata = true on the ones you'd like - would that work for your use case?

[nyurik]

might be a bit difficult - take a look - https://github.com/kartotherian/osm-bright.tm2source/blob/master/data.xml - for example, all params are cdata

[nfarina]

Are you generating this XML from scratch? Or parsing an existing document? If you're parsing an existing document, then isValCdata will already be set on the elements that came in as CDATA. If you're building it from scratch, then you would just set that property to true for all params.

[nyurik]

i parse it in and alter a few values

[nfarina]

So when you parse CDATA tags does it correctly "round-trip" them back to the toString() function? If this works for you then I'd rather go with this method since it gives the developer control over the output. I find the idea of conditionally outputting CDATA based on content a bit strange - although I'd love feedback from other developers here.