@edvin True that, but it'd mean mixing formats in the same file. I don't like that.

@edvin 🙈 Ah oky sorry my bad

@permalmberg @edvin @nimakro I used to support a product called Alfresco which allowed both XML and properties. That was a while ago. Maybe various formats can be included? I ended up supporting the properties file because of the aforementioned help for support. nested properties weren’t really a problem because I had a dot notation. I think if the data structures are too complex, there’s probably a coding gap (different Providers with lighter configurations, etc)

I guess if the file should be edited by ops they should keep the json on a single level

Well if

JsonObject

is not writable, we probably should implement a new

Config

object which allows changes to it and which can be written as

json

or

property

file

@carlw I guess that was done by

Properties

, because it actually supports XML out of the box as an alternative to flat files?

@carlw imho, setting files should not be edited manually.

@nimakro That's maybe the best alternativ. Then we don't have to change the API if we want to change the underlying storage engine again later.

@permalmberg there were a number of configuration options, search index options, urls, data sources, etc that needed to be configured for the deployments

@permalmberg I don't agree with that. Settings files might need to be edited manually to adapt for certain situations. Try telling a linux admin to never edit a settings file manually 🙂

@carlw @edvin yeah, yeah, I know. I touch setting files all the time... 😛 But if the app has an admin interface, then the files should be hands off...

@permalmberg Yes, but you might have settings you spesifically don't want users to edit, so there is no UI for them 🙂

Well but I think there is a difference between a settings file generated by the app (which should not be manually changed) and one which is configured for deployment to be red by the app (which is more a resource file to for me and can be changed manually by support people)

@edvin good point

All good points here.. hehe.. where should we take this?

K.I.S.S

@edvin So should I start with a test implementation for the new

config

helper on a new branch and make a pull request so we can discuss more ideas with some code?

@nimakro Good idea

@permalmberg @edvin For this Alfresco work…this was the “last mile”…the 4 or 5 settings that would get the admin interface up-and-running

btw, how do I make Slack stop scrolling up everytime a message arrives?!

Slack keeps marking messages as "new" all the time...

There was no widespread editing of deeply-nested config files at a deployment

@permalmberg pane.viewportBounds.minX=<fixed value> ?

@carlw No, I use

pane.viewportBounds.minX

as an offset for positional calculations.

val vm = ComponentVM(c)

			val offset = view.getScrollOffset()
			val localPosition = view.sceneToLocal(event.sceneX - offset.x, event.sceneY - offset.y)

			vm.x.value = localPosition.x
			vm.y.value = localPosition.y

override fun getScrollOffset(): Point2D
	{
		return Point2D(pane.viewportBounds.minX, pane.viewportBounds.minY)
	}

@permalmberg i meant for configuring Slack 😀

@carlw Oh. 😄

@edvin Oky will do.. Oh and should we kepp the name

config

or should we call it

settings

😀 because for my a

config

file is what developers edit manualy and

settings

are defined by the app 😃 but I don't want to start a religous war again😜

well...son of a --- 😞

pane.viewportBounds.minY

isn't always up-to-date

I loath having to do

pane.requestLayout()
		pane.layout()

. Oh well...

time to play some Eve Online. Thanks for the help guys.