prettyPrint indents too much, spurious newlines may also break indentation

[Leif-W]

Debugging becomes tiresome with sloppy formatting.

The indentation level often seems to double-indent.

Newlines are thrown in at the end of nodes/loops, adding blank lines which break formatting.

These spurious newlines begin the next line with no indentation thus breaks formatting.

prettyPrint comment don't expect too much, well, either it prints pretty, or it doesn't, and it doesn't, so... either we fix, or maybe halfassedPrint would be a better name. ;)

[soldair]

happy to accept pull requests for these suggestions/bug reports. i don't have time to work on it now but if this is useful to you maybe you do?

[Leif-W]

This will take a little more investigation to get it just right. Will submit pull request when I resolve the issue! This module is used in Mozilla's new/deprecated jpm tool to generate RDF files. Just an itch to scratch.

Edit 1: Upon further inspection, there are three problem areas. I am just noting them here for future reference. Although these issues pop up within the usage context of the jpm tool, I think they are generally relevant for many other non-trivial XML files. If I can find a way to improve things, I will certainly contribute it back.

1. Part of the newline problem seems to come from the way the jpm tool creates the install.rdf file, which can contain multiple instances of the same tag at the same nesting level e.g.:

<em:developer>Developer 1</em:developer>
<em:developer>Developer 2</em:developer>

Which can't be trivially added as a single object property, as the last Developer would clobber out the previous. Their solution was to put each developer wrapped in it's own object, which has the side effect of generating an additional newline. Not yet sure how to approach this, am trying to both modify the jpm RDF generation code, and also the jsontoxml newline decision.

Edit 2: Haven't had a chance to look into this, but had an idea that I need to note down. The problem is that multiple instances aren't allowed because it would overwrite the JSON object property, but the solution is simple: make the property value an array, not a string. The array value would then be detected and used to indicate that we have a list of tags of the same name. It may well be that jsontoxml does this properly and that jpm is just using it incorrectly. If that is the case, great, then the problem is reduced to mere documentation update to more clearly communicate proper usage. If not, then I'll try to work on implementation. I'll test this either way when I have time.

2. A second problem is that the object seems to double-or-triple-indent when the resultant code would merely have a single indentation. Again, part of this is the way the jpm RDF code is written, using array pushes to construct the object, such that the json object itself begins with an array that contains the top level XML tag.

[{
    "name": "...",
    "attrs": "...",
    children: [{
    //...
    }]
}]

It would be ideal if the jpm RDF code constructed a more simple object without redundant nesting, or so much reliance on array pushing. But as mentioned, there are several other tags which may be used multiple times at the same nesting level, so it might be unavoidable.

A more tricky way would be for jsontoxml to keep track of what is actually a node with content versus an empty nesting. Increase indent only when in a new object AND content is added to the XML string, not JUST whenever we step inside a new object.

3. Somewhere when heading back out of the final nesting, the indent level is forgotten entirely, still looking into that. But then it seems to resume just before the final 2 outer tags. These may again be quirks resulting from the way the jpm rdf code generates the xml. To what extent possible, I will try modifying that code to alleviate such issues.