Hi Gus,
See the first post why the fpjson unit didn't work out. I do use it in another part of the application I'm building, but it won't work for deserializing.
To explain what I'm doing: I have to communicate with a large REST API (thousands of functions with often large data structures). That's a lot of work to implement. And it changes frequently. They do have description files, in RAML and OpenAPI. That's both YAML. So, it seems to be best to parse that and generate a big node tree, that contains all the functions, enums and data structures, and the references between them. Which is what I did. Which wasn't easy, because almost every text is valid YAML. It's very unstructured.
You get the parameters and body belonging to a function (by name), fill them in and call the function. Those parts are serialized and send to the webservice, the response is turned into another node tree. Which you then can process. I'm thinking of adding a DataSet interface as well.
That way, it is fully dynamic and I don't have to make (or generate) a class for each data structure, and can automate calling them.
And as it turns out, I've written most of that myself. There is no FP YAML, RAML or OpenAPI parser that I know of. Or extended, serializable nodes. I do use library functions and objects, of course. TSTringlist, some containers from Generics.Collections, Variants, LazUTF8 and fphttpclient. And I follow all the conventions, my classes look the same and have the same methods as the default ones.
For the other side of the application, I made some custom variants of default Lazarus components, like TDbf. And a large library of helper functions, of course. I did post a few bugfixes on the bugtracker, and I have more, but the last one is not accepted yet, so I have forked my own libraries.
That's how you do it, right?
And treating components as black boxes is fine, if they do what you want them to do. If not, you need another one or write your own.
Greetings, Frank