I have a concern about an EMBT skills video: JSON: the new INI File by Jeff Lefebvre.
I have a concern about an EMBT skills video: JSON: the new INI File by Jeff Lefebvre.
I like the idea very much, but how is streaming JSON going to work once your Settings class start changing over time? eg: Some properties in the class get removed or renamed. How will that affect reading the JSON file, and how do you handle those changed properties (old vs new)?
https://youtu.be/e6IKO8so-Is
I like the idea very much, but how is streaming JSON going to work once your Settings class start changing over time? eg: Some properties in the class get removed or renamed. How will that affect reading the JSON file, and how do you handle those changed properties (old vs new)?
https://youtu.be/e6IKO8so-Is
Well, you could have a RTTI oriented INI handler as well ;)
ReplyDeleteTIniFile.IniToObject<>()
I have really complex data structures that I currently save to INI file, but it is a real pain to read/write to INI. JSON's built-in data types, arrays and nested structures support seems ideal for my needs. I'm just a bit concerned about using the streaming support (to read & save) regarding changes to my Settings class over time, and how streaming - especially reading an older JSON file after the Settings class was changed.
ReplyDeleteGraeme Geldenhuys I vote for using sqlite for storing settings... it's much more easier, flexible, everything in one file, relations, translations, etc.
ReplyDeleteall we need in the delphi/pascal world is a wrapper around the sqlite engine to save/load objects via RTTI(something like, create table if not exists "COLOR_SCHEME"), each record can be a field, etc.
It's up to you how you handle this. Personally I think that tying the names in a human editable text file to the names of an internal record is rather short sighted. As you correctly identify, code changes over time. An RTTI based approach makes it much harder to deal with that. The advice given in this video seems rather naive to me for that reason.
ReplyDeleteIt was also a bit odd to see TStringList being used to read the contents of a file into a string. The author seems not be aware of TFile.ReadAllText.
David Heffernan I didn't know TFile.ReadAllText...but after looking at the code behind this, I'm not sure I'll keep it in memory...
ReplyDeletePaul TOTH IOUtils is not my favourite unit. If you don't like it, it's still worth adding your own helper to read a file as text. Using a string list is pretty bone headed in this scenario. First parse the text into lines. Then recombine them into a single string!!
ReplyDeleteWhat I like with JSON is that it is can easily serialize a set of nested objects. In https://github.com/synopse/mORMot/blob/master/SQLite3/DDD/infra/dddInfraSettings.pas we store all settings in a TDDDAppSettingsStorageAbstract = class(TSynAutoCreateFields), which is persisted as a JSON file or on a centralized server. The class can have nested objects, and even arrays of objects. All instances are instantiated and released automatically: you do not need to override Create nor Destroy for handling the memory. Enumerations and sets are serialized as strings, with proper comments to identify the potential values. There is also a remote administration tool, which allows to read or update the settings in real-time, without the server restart. At compile time, adding a new property is directly handled by the main class, which would add it to the JSON, with its default value. With have a set of dedicated classes, ready to be used in your settings, e.g. to instantiate a REST client, a REST server, an ORM storage over a given RDBMS or NoSQL/MongoDB, logging information, remote administration, a TCP server (used e.g. for IoT connection)... It is very efficient and easy to work with.
ReplyDeleteI would never go back to plain flat .ini file.
The Q&A session was a bit odd. Presenter was asked about advantages of JSON over XML, and responded that the file size was smaller with JSON!
ReplyDeleteEr, the advantage is that JSON is more readable for humans. Not quite as clean as YAML but there you go. Of course, for very simple config files, INI is more readable than JSON......
David Heffernan yes, the purpose of INI file is to be edited with Notepad, JSON has another purpose.
ReplyDeletePaul TOTH But JSON could still be easily edited with Notepad, as soon as it is written with some basic indentation and line feeds to be human readable.
ReplyDelete+Paul The big reason why JSON has taken over from XML for structured config files is that it is human readable, and human writeable.
ReplyDeleteDavid Heffernan : I would add... because JSON also has built-in data types. String, Integer, Arrays etc. That's my main attraction.
ReplyDelete+Graeme Nobody says you have to use rigid RTTI with JSON. You can be flexible, and use JSON.
ReplyDeleteA. Bouchez David Heffernan I know, but JSON don't accept comments...It will be a nightmare to use JSON on httpd.conf for isntance...not exactly a INI file, but close to.
ReplyDeletePaul TOTH A lot of settings file using JSON do have JavaScript like comments. It is not standard JSON, but handled by most editors, and easy to ignore at parsing. This is what we support for instance in our framework - and the comments are auto-generated from the enumerations and sets RTTI.
ReplyDeleteDavid Heffernan : I fully understand, and have used JSON (without RTTI) before. So basically the youtube video is just a rubbish idea, and what is portrayed in the video is definitely not a good design (or scalable) for replacing INI settings file functionality. Using JSON (without RTTI) will be fine though - I'll go that route.
ReplyDeleteThanks for everybody that contributed in this discussion.
Paul TOTH YAML is the thing ......
ReplyDeleteGraeme Geldenhuys You can use JSON and RTTI, and be pretty flexible. I do not see any issue with using JSON and RTTI, as we do for configuring our DDD services.
ReplyDeleteDavid Heffernan I hate all those languages and formats that use indentation for semantic ;)
ReplyDeleteI remember an error on CoffeeScript with
f x + 1
instead of
f x+1
+Paul So you don't bother using indentation when you write code?
ReplyDeleteI do, but I don't want that the compiler return an error because they're 2 spaces instead of a tab or because I add a blank line in a begin/end section.
ReplyDeleteas I said sometime ago, Delphi could add warning based on indentation but not compilation error.
if condition then
step1;
step2; // warning, suspect indentation
step3;
What I like about semantic indentation is that you avoid repeating yourself. To me it is wasteful and error prone to use both indentation and source code to specify structure. In most languages we use both and so repeat ourself. In Python and YAML we can avoid that. I have much experience of both and can say that semantic indentation has never caused me problems.
ReplyDeleteA. Bouchez : I fully understand you can use JSON via RTTI to persist objects... I'm referring specificially to the use-case presented in the YouTube video. That seems like a terrible idea, because what if you have JSON data stored, then modify the Settings class (rename published properties or remove properties), and then try and load a older JSON file. The video gives no solution for that.
ReplyDeleteGraeme Geldenhuys this is where convention over configuration has its limits. You have to follow the conventions otherwise you got unexpected results.
ReplyDeleteGraeme Geldenhuys you have the same situation with DFM/FMX. Firemonkey use TPersistent.DefineProperties to map older properties to new one. My JSON Unit supports a JSONParseField method for the same purpose. Perhaps JSON's Converter and Reverter can do the same...not sure of that.
ReplyDelete