3 ms·
> It might just be personal preference here, but I look at that thing and shudder. Can you imagine authoring that? Maintaining it? Isn't the problem more the t
by thangalin 4y ago
> It might just be personal preference here, but I look at that thing and shudder. Can you imagine authoring that? Maintaining it?
Isn't the problem more the tooling than the configuration language specification? Can you imagine authoring office documents by hand? Or maintaining them?
My text editor, KeenWrite, allows users to reference YAML variables as paths while editing documents. The editor includes a collapsible tree view of the variables, which makes navigation and maintenance a breeze.
https://i.ibb.co/qp0vj1Q/yaml-editor.png https://i.ibb.co/qp0vj1Q/yaml-editor.png
Also, when inserting a variable into the document, the YAML tree expands automatically to the location the variable is defined. From the end user perspective, the data format is irrelevant.
Here's an example that produces a user-friendly UI for a JSON schema:
https://json-editor.github.io/json-editor/ https://json-editor.github.io/json-editor/
- jerf 4y ago"My text editor, KeenWrite, allows users to reference YAML variables as paths while editing documents." Another thing that would help in these template languages is if they'd pervasively track the sources of things, and let you view the final output of the templating process with some mechanism for viewing those annotations. Then when you look at the final result of some templating operation and can't figure out why "AWS_ENV_VAR" is "lol don't deploy this", you have some chance of figuring out where it came from. This is yet another entry in the class of things that aren't too hard to add from the beginning, but good luck retrofitting it on after the fact.