Node-red-contrib-fastxml needs update?

[gregorius]

Hi There,

I just spent a good hour wondering why this didn't produce the same svg as inputted:

Turns out that the options have changed to:

const options = {
     ignoreAttributes: false,
     attributeNamePrefix : "@_"
};

The codebase uses:

options.attrNodeName = node.attrkey || options.attrkey || '';
options.textNodeName = node.charkey || options.charkey || '_';

I pass in the new options by setting them on the msg ... after finally finding the problem.

// Att: @dceejay

[dceejay]

Sorry, not understanding the problem… it was a conscious choice that the default creates a flatter object.

[gregorius]

Perhaps I made the wrong assumption that if the node converts xml to objects and objects to xml then the input xml would match the output xml when the node is chained together.

Seems that assumption is incorrect.

[dceejay]

:-). In this case yes. The core xml node does do that. But I found that the objects it produces are a pain to work with, so have chosen a different path.

[gregorius]

I don’t know what the xml node does since with the svg I’m working with it just errored out with a buffer too large error

[dceejay]

Sounds like that is the one that needs an update !

[gregorius]

Would probably be better to replace it with yours but with the features of the original node

Why have two when there could be one that covers both use cases …

[dceejay]

I did try that but I couldn’t get the output objects to be 100% match even with @_ etc. so rather than break it I went with definitely different

[gregorius]

The curse of the backward compatibility zombie … something that haunts all good projects!