@nimakro Not sure, we have so many ways of doing almost the same now. config, preferences and now settings (!) 🙂

@edvin I know, I didn't mean to add another one, it was more the question if we rename the

config

helper 😀 while I am implementing the new

config

helper, but I can gladly keep

config

😉... Alright I so I will start with re implementing the

config

helper and then we can discuss more as soon as I have some code.

OK, great 🙂

@edvin Let's say every app has one global config, what would be a clean way to access that config from a component, would I add a property to the

scope

so I could get it in the

component

class? Or should I add a property globalConfig to the

FX

class? 🙈

@nimakro Let me think about that for a while, OK?

@edvin Yeah no rush I have enough other things to work on 😉

Great 🙂

Lest's say we want to store the following data in a config file

{
   window : {
       x: 30.0
       y: 40.0
       list: [2,3,4]
  }
}

Which of the three variants would you prefer:

config {   
          // Nested config values example
          
          // 1. Variant
                   set("window") to {
                       set("x" to 30.0)
                       set("y" to 40.0)
                       set("list" to listOf(2, 3, 4))
                   }
                   // 2. Variant
                   set("window"/"x" to 30.0)
                   set("window"/"y" to 40.0)
                   set("window"/"list" to listOf(2, 3, 4))

                  // 3. Variant
                   set("window.x" to 30.0)
                   set("window.y" to 40.0)
                   set("window.list" to listOf(2, 3, 4))
}

or should we support more then one of the following variants?

@nimakro this looks more like object serialization rather than config? Have you considered a model component backed by a file?

@carlw Yeah it's kind of object serialization, but the example above is more for the use case where you have a bunch of settings in the ui and you want to structure them hierarchical but don't have an object for it just properties. Most of the code uses the `config`helper already existing in tornadofx. I am just playing around with ideas for the new

config

helper api

I think the cleanest way to deal with config settings like this is to create an object that extends JsonModel and save it as a resource. Don't know if this should be the primary use case for

config

.

It may be. Need to think about it a little.

That said, I like variant 1 best.

@nimakro by object serialization, I don’t mean a field-for-field copy like Java Serialization. There can be some impedence, say you’re building your window shapes from an industry-standard format that deviates from your internal data structures. In that case, the drawing of the UI and the positioning of elements — say the settings from the last session — need to be serialized, but don’t need the same type of treatment and exposure as a config file of URLs, servers, or datasources which are expected to change from deployment to deployment. I think human-readable files are fine, especially since they can help with testing and support (send them over if there’s a problem). It seems like this is a plain model to me. “config” to me means being able to get to the files in a known location, possibly overriding what’s there. For example, pack a config file filled with defaults like “localhost” and allow the user to add a new config file on the command line with a -D or $HOME/.myapp/myconfig.

@edvin So sounds like you would like to keep the flat file style for now for the

config

helper.. so I will only add the

COMPONENT

GLOBAL

scope stuff to the implementation for now and then we can see if we need other features in the future? Did you think already about were the best place would be to store the

GLOBAL

config object? @carlw That makes all sense and I see what you are saying but my original question was more related to the syntax for the new

config

helper api, and in my opinion it is nice to have support for json files and have a nice way to easily retrieving those properties pragmatically from within the program

@nimakro if your code example indicates what you’re trying to do, i implemented a similar requirement to save the current screen config. I also needed to provide fault tolerance so that any failures were ignored (the file is re-generated). That doesn’t fit my typical config use case where you’d like to fail fast if you’re missing key information.

@carlw No I think you are miss understanding me I am currently not trying to save screen stuff (

window

was just en example), I am working on some improvements (at least I hope they will be improvements 🙈😀) on the tornadofx

config

helper api and was just trying out different api syntax to save and restore config items.

got it. i think @edvin is preparing a file-based jsonmodel. It would be a good complement to workspaces to implement a save last workspace feature

Sorry guys, I'm lagging behind today. Will try to catch up tonight!

I'm working on lots of functions for loading and saving Json objects and JsonModel. Will commit soon. It might make it easier to play with

config

as well @nimakro

I added the following functions for now, suggestions for more are welcome:

@User uploaded a file: Functions to load/save JSON

@edvin the load/save functions are looking good, thank you!

@nimakro Sweet! I think they can make working with JSON a lot more pleasant. I'm thinking about adding write support without copy on write as well to JsonObject. Trying to figure out how much work it would be.

@edvin Did you already have time to think about were the best place would be to store the

GLOBAL

config object to allow:

config(GLOBAL) {
     set("username" to "name")
}

@nimakro I think your suggestion to use the app class is great :)

@edvin Oky, is there a nice way to access the app class from a component ( sorry for all those questions 🙈 still getting to know tornadofx)

@nimakro Maybe I misunderstood you. I meant the config property for where to put that global file. The GLOBAL enum might as well be inside

Config

? We would do

class Config : Properties

to keep compatibility. Then we can pretty easily add an option to use json format for config files inside

JsonConfig

perhaps.

JsonConfig.configFormat = JsonConfig.ConfigFormat.JSON

instead of the default

JsonConfig.ConfigFormat.PROPERTIES

perhaps?