SAX dumper

[Al2Klimov]

Like the SAX parser, but for dumping. A class with methods called by the using app instead of being called.

[nlohmann]

The whole logic for dumping is in file https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/output/serializer.hpp which implements class serializer with constructor

serializer(output_adapter_t<char> s, const char ichar,
           error_handler_t error_handler_ = error_handler_t::strict)

and a public method

void dump(const BasicJsonType& val, const bool pretty_print,
          const bool ensure_ascii,
          const unsigned int indent_step,
          const unsigned int current_indent = 0)

taking that implements the traversal.

Some thoughts:

• We could add an overload of basic_json::dump that takes a serializer-like object and uses that for serialization. This would mean that if someone wants some user-defined serialization, she must provide the complete implementation for this.
• Alternatively, we could define a SAX-like interface like dump_string, dump_integer, etc. which separates the logic from the representation. However, I fear that there are so many possible adjustments people want to make to serialization, that it would be impossible to foresee all of them in the interface.

What do you think?

[Al2Klimov]

The second one sounds exactly like the issue description.

[nlohmann]

@Al2Klimov Right, but there are still a lot of details to decide.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Al2Klimov]

@nlohmann Interesting... is that this feature request's end?

[nlohmann]

No, it's just no-one commented on this for 10 days, and I had no time to look into it.

[Al2Klimov]

I'm not stressing you... but I'm afraid the bot does.

[nlohmann]

The bot is not stressing me. :)

[Al2Klimov]

At least it may let some tickets disappear. For me a closed ticket stands for the subject is either done, rejected or a duplicate.

[nlohmann]

This is a feature. The project is run by a few people in their free time. A lot of issues are feature requests that may need a lot of time to realize, test, and document. If these issues were left open after months of inactivity, then this would be more of a pressure. And since they are labeled "stale", it is hopefully clear why they have been closed.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dnsmichi]

Just a heads up, since I wanted to add my thoughts here too: We really appreciate all the work you're pushing into this project. The replacement of the old YAJL library went smooth and all the dependencies in Icinga 2 work better now, including proper UTF8 support. The first release will be 2.11 soon enough, and we'll sure highlight your work in the release blog post.

That being said, this feature request would be nice to have. Since we're all involved in open source projects, time and resources are needed. Given the difficulties with the interface design here, I'm not sure if that works out, especially with later supporting it. I've seen similar problems with Boost Beast and custom parsers lately. Looking at our code base (https://github.com/Icinga/icinga2/blob/master/lib/base/json.cpp), we also have some specialities with custom value types not so common in the C++ world. I'm fine with it, and if we find the time to create a PoC or discuss this in person, we'll see about it.

For now, thanks for taking care :)