Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

render() output should be configurable when path did not exists #444

Open
schmitch opened this issue Dec 16, 2016 · 3 comments
Open

render() output should be configurable when path did not exists #444

schmitch opened this issue Dec 16, 2016 · 3 comments

Comments

@schmitch
Copy link

Actually when merging a config with new values, while the path did (using ConfigDocumentFactory.withValue("not.existing.path", newValue)) not exists the output of the configuration is always in the following form:

a : { b : { c : { d : { y : 0 } } } }
// or with multiple keys
a : { b : { c : { d : { y : 0 , x : 0 } } } }

However I think it might be suitable to actually configure this output to at least use a more "normalized form" like:

a.b.c.d.y = 0
// or
a.b.c.d.y = 0
a.b.c.d.x = 0

just for readability.

@havocp
Copy link
Collaborator

havocp commented Dec 22, 2016

Maybe there's a rule like "use dot notation if there's only one child"?

a.b = {
  x=10
  y=11
}

So b is dotted on to a since there's only the one child of a

Not sure if that's the best heuristic or not to get something that seems pretty.

@schmitch
Copy link
Author

schmitch commented Dec 22, 2016

Well I actually would prefer to have it configurable since we would prefer to have them dotted even with multiple childs.

I would probably come up with a PR as soon as the project where we use that function needs it (probably in one/two month(s)).

We actually use it to change configuration from the console and from a web interface. and it will render it extremly non human readable once the config got missing/rewritten from the web interface.
Well

a.b = {
  x=10
  y=11
}

would be a improvement but I guess it's harder to do than the everything dot notation.

@havocp
Copy link
Collaborator

havocp commented Dec 22, 2016

Configurable is a harder patch to write, but could be OK if the configuration knobs seem fairly logical and likely to all be useful. There are 1000 ways to format things, don't want to support them all, though. Would prioritize having a nice default over trying to be an arbitrary-personal-preferences formatting engine. Config knobs would maybe be something very high-level like "always flatten (no braces, only dots)" vs. "smart flatten (use dots when there's a single child)", I don't know.

I suspect both of these conventions are fairly easy to implement.

ConfigDocument is supposed to be retaining existing formatting for stuff that was not modified, of course (if I remember right at least).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants