possibly adding holistic JSON support preparation to any oo C++ (17++) project

[u-an-i]

JSON as output from the webserver appears to be a common fundamental requirement for catalysing future web-based community add-ons (for private or public use)

// I just noticed std::function requires the name of the class of which a method is being wanted to get assigned as a pointer ;( I hoped i could get around this - ah: perhaps you can add a protected list of pointers to member functions to JSONProvider. Your class inheriting from JSONProvider might make adding your getters to that list possible due to polymorphism. Then register the map with the index of the pointer to a member function as the value of string. "getValueByMethod" would then be "getValueByIndex" and would use the list to call the member function ! :)

proposal:

• create a complete-application-wide available class having only static members, 1 or 3 static methods and 1 overloaded operator, name this class JSONStorage.
• create an all-class-accessible class having 1 constructor, 1 or 3 public methods and 1 protected member, name this class JSONProvider.
• let JSONStorage be a friend class of JSONProvider.
• let JSONStorage's 1 static method be public: "register" taking a JSONProvider and a map of strings to std::function<QVariant(void)> or create 3 public static methods, 1 for every primitive JSON data type (bool, double, string), eg. registerBools taking a JSONProvider and a map of strings to std::function<bool(void)>
• let JSONProvider's constructor take either a map of strings to std::function<QVariant(void)> or 3 maps of strings to std::function<JSONDataType(void)>, 1 for each such type, let JSONProvider's 1 public method take 1 std::function<QVariant(void)> or 3 public methods each take 1 std::function<JSONDataType(void)>, name this(/these) method(s) "getValueByMethod", declare the protected member as string named "sourceClassIdentifier".
• Implement (every) "getValueByMethod(pointer x)" as "return x()". It would run the pointer in the context of its originating object.
• Implement the constructor as "JSONStorage::register(this, mapOfStringsToQVariantMethodPointer)" or appropriately if and for the 3 primitive JSON data types variants.
• Implement "register" / "registerX" as storing mapOfStringsTo_Y_ as an entry in a list being a private static member map's value to the key JSONProvider->sourceClassIdentifier. (that map is a map of strings to list of mapOfStringsTo_Y_.) Store JSONProvider in a map of strings to JSONProvider* (pointer).

Now:

1. let all (to your liking) classes of yours inherit JSONProvider
2. set the "sourceClassIdentifier".
3. call the super constructor of JSONProvider with a map of strings to method pointer where each string is a string of your liking representing the method it is mapped to, suffixed by "_static" or "_dynamic" depending on whether you consider the data the method delivers as static or dynamic with regards to the flight sim. Each method is a getter of your class to a value of your class representing a data property you want to expose from the web server(, assigend using std::bind(methodname) (// not sure)).

Then:
Implement overloading of operator >> in JSONStorage to output (to) the JSON class from https://github.com/nlohmann/json on request from the webserver. Using overloaded operators requires an instance. Call getValueByMethod on every JSONProvider stored for every method pointer stored passing that one, storing the result as/for a https://github.com/nlohmann/json JSON object.
For now, output all data. In future perhaps output only values of properties requested.

The JSON can look like the following considering you have 1 instance of your class X running and 3 instances of your class Y running:

{
 "Xidentifier": {
    "static": {
      "boolProperty1": false,
      "boolProperty2": true,
      "doubleProperty1": 1.345
    },
    "dynamic": {
      "stringProperty1": "test"
    }
  },
  "Yidentifier": [
    {
      "static": {
        "doubleProperty1": [1.3, 80.4]
      },
      "dynamic": {
      }
    },
    {
      "static": {
        "doubleProperty1": [1.5, 80.2]
      },
      "dynamic": {
      }
    },
    {
      "static": {
        "doubleProperty1": [1.7, 80.1]
      },
      "dynamic": {
      }
    }
  ]
}

Practical occurrence:
Y could be a waypoint class whose "doubleProperty2" is its position.

Note: I forgot getting Arrays and having objects of a Class which might itself inherit JSONProvider be a member of a class inheriting JSONProvider needs to be thought about.

The tedious part is assigning all property names. But you could start with exposing only 1 or 2 classes values. Anything else as time comes by.

delta data and rate data would be provided by web client code based on what its authors could achieve with the static and dynamic data.

Remaining: documentation of properties for VFO authors #661 to make use of them.

[albar965]

No sure if I understood all of the above. May brain is a bit slow today.

I'd prefer to use Qt JSON for the implementation. Using third party libraries is ok if they can be copied to atools (if license allows). Maintaining and compiling third party libraries like Marble for three platforms is not really funny. Especially macOS is a pain.

Deriving for POD objects/structs like map::Airport or (not POD) atools::fs::sc::SimConnectUserAircraft: I'd rather avoid this and leave them alone. Instead create a kind of shadow/adapter class (maybe friend of above) which can extract all or single values in JSON. I'd also not use Qt properties since these come with a lot of overhead.
Apart from that I'm open for all.

Classes which might contain relevant information:
https://github.com/albar965/atools/blob/master/src/fs/sc/simconnectuseraircraft.h All aircraft related data but also environment like current weather around aircraft. Fetched from simulator and updated few times a second. Can be serialized to binary.

https://github.com/albar965/littlenavmap/blob/master/src/route/route.h All flight plan related stuff including all legs as well as next active legs information.

https://github.com/albar965/littlenavmap/blob/master/src/route/routealtitude.h TOC and TOD calculation, vertical profile as well as everything needed for fuel report. Contains partially redundant information for Route.

https://github.com/albar965/littlenavmap/tree/master/src/query Database access wrappers. Mostly deliver POD structs and sometimes SQL Records from the map namespace.

https://github.com/albar965/littlenavmap/blob/master/src/common/maptypes.h Above mentioned POD objects. Most are serializable and passed around throughout the whole program. Inherit from base but don't have virtual destructors which needs a bit caution when dealing with these things.

Edit: Not at C++17 yet. Will try this after the release.

[u-an-i]

Qt : sure! btw. nlohmann states it's single header no extra build process etc. which I found very welcoming :)

Thank you! If / when I tackle this i start there!

Discussion original is perhaps better for a C++ forum :) It's my theoretical musing.

[albar965]

Single header is perfect. Like this stuff already: https://github.com/albar965/atools/blob/master/src/geo/nanoflann.h
But I wrapped it here to avoid including this thing everywhere.

[u-an-i]

the idea behind the op is, on an existing class hiearchy, to add support to collect values from classes of this existing hiearchy to somewhere (eg. to output it as JSON from there) while not touching the existing classes at all, in particular not write "custom" transfer code or extend individual value creation methods.

Unfortunately this appears not possible by passing method pointers around: i forgot: to call a method of an object, the compilers type-safeyt I guess, must know the method exists on this object. This means,as long as the getters are defined first in the class to add value collection from, a pointer to any such getter must include the class name for the compiler to know this pointer can call the getter.

Touching existing classes not at all isn't achieved by the op anway but at least not every getter has to extended with "custom code".

The goal to have minimal intervention on the existing class hierarchy can still be achieved though I think ( I apologize for making you spend time in vain so far and causing disappointment to expectations I let rise):

the constructor of any existing class to collect data from must stil be extended to call JSONProvider's super constructor with the information about the available "properties" (as to be collected) by passing their names as spec'd in the op. But nothing else has to be passed. Instead:

add 1 or 3 pure virtual functions to JSONProvider taking a string. This string is to get passed the representative property name you came up with, name the pure virtual function getXProperty where X can be QVariant, Bool, Number or String.
Inside your existing class for which the intention was to not touch it, implement "X getXProperty(String propertyName)":

switch(propertyName) {
  case "myThoughtOfRepresentativeName1" : return getCorrepsondingValue();    // getter is your existing getter which gets the property in question
  ...
}

This way, maintainance of your code per getter/property is boiled down to 1 line of additional effort.

The elephant which was running at us is the creation of a special JSONProvider per existing class or changing every getter of every class with -- granted 1 line only too -- but several identifying identificators like JSONStorage::storeBool("propertyname", "classname", value, instanceidentificator) but which would run actively on each get rather than waiting passively or creating Templates out of your existing classes or .... .

I hope this works. you = dear reader.

CC @albar965 , i havent written C++ the last 18 or so years (glanced at C++ 11 for a time some 8 years ago). -- oh wait, i coded a Symbian Belle Nokia OVI store app with Qt around 9 years ago :)

Other than Qt JSON or i think i understood your approval of the nlohmann header, do you have any other recommendations?

looking forward to read from you, enjoy

[u-an-i]

Addendum: i just wanted to elaborate on the conceptual erring i made in the op and present a general C++ alternative. I got your points of your first reply, particular atools et al! (Although I'm not sure I really should do what you wrote: friending all "problematic" classes and just retrieve their properties directly with the "collector" ? :) anyway, i'm just starting up my engine wrt C++ again and am not familiar with (any/all) LNM source code (yet) thus i will need time ... :|

[albar965]

I'd go step by step.

1. nlohmann stuff looks very good. Much easier than Qt JSON classes. I'd add the whole library to atools (try to avoid the header only if doable and license permits).
2. Do not friend any classes. Not needed since all have required getters.
3. Wrap only classes that are needed for a better web UI now. Do not wrap without need.
4. Do not wrap POD or other small objects but let large wrapped classes for Route, MapQuery and others return JSON objects where a return type is map::MapAirport, for example.

Alex