Using a Config/Properties File for your Application

We use the same ini file that we use for OE info...just added a section for our app. This is for session info.

We also use XML for 3rd party integrations (EDI, FTP, etc.). If we were to do this over we would use json.

I had the same thought Mike, but was concerned about the possibility of the user editing the file in a way to invalidate the JSON data. Maybe the likelihood of that is low.  

Unfortunately, support for INI files is windows-only.

Do you have a UI to maintain the XML or let the users modify directly?

A bit of both. Some files would never be updated by the users and really never change so  we distribute a sample that our reseller would modify. The others where the data may change we use the UI which will read in the XML, allow the data to be updated and then write the xml back to disk. This same approach would work for json.

Unless you provide an editor with some form of code completion/validation it doesn’t really matter what format you are using, if you let the user freely update the configuration file he might well broke it… depending on the format/way you read the configuration you might end-up with invalid/partial configuration or no configuration at all, either way better fail short and drop the ball right there after you inform the user the config is broken :)

Waaaay in the past, I have done this...

Issue 3 uses a database table (www.oehive.org/.../ezine3.pdf) .  With all the remote access to databases expected these days, that is the best place to put it - otherwise you might need to move configs with movement of clients.  Moving between environments (dev, test, prod) is merely moving the data.  Issue 3 also gives lots of types of parameters that are stored too so take into consideration what gets stored.  (Later on, I was storing HTML in configs as it was searched by {customer, app, parameter} so take that sort of thing in mind!)

Issue 6 (www.oehive.org/.../ezine6.pdf ) expands on Issue 3.  The code for both is at www.oehive.org/.../ .  It also includes code for making the files.

I would use XML now days to store stuff.  JSON might be "hot" but it is very web oriented.  One can use it multiple interfaces (CHUI, GUI, WWW, Mobile) but storing things such as base64 and the like might be taken into consideration.  XML is better for that.

Essentially what I want to do is to have some advanced options on our server that are configurable with a config/properties file. The goal was not to provide a UI for it but just allow the admin to edit as needed to enable said advanced options.  I wish the GET-KEY-VALUE, etc. constructs that OE has would work on any platform and given properties file. :)

Sorry if this is a duplicate...

Essentially what I want to do is to have some advanced options for our server that are configurable via a config/properties file without having a UI for it. So human-readable is important.

The GET-KEY-VALUE construct that OE has would be perfect if it worked for all platform and any given property file. :)

For my DataDigger I use a set of .ini files. One is for settings on file datetimes so DD can recompile itself when needed, one is for user settings and one is for help messages. I chose ini files because they are human readable and can easily be edited outside of the application. Plus, everybody and his mother knows the structure of ini files.

At first I used GET-KEY-VALUE and PUT-KEY-VALUE, but since DataDigger heavily uses its settings, this became a performance issue. So now I read the complete ini file into a temp-table and serve the settings from there. When settings are written, they go both to the cache TT and the ini file on disk. My read/write ratio in DD is about 100:1 so a lot is read and less is written.

So why you don’t just use a simple properties file format like Java, hell, make it even simpler by not allowing a property to span multiple lines…

Thanks all for the input.

"So why you don’t just use a simple properties file format like Java.."

That is what we were/are leaning towards; I just wanted to see if there was a "better" way that we had not considered.

"So why you don’t just use a simple properties file format like Java, hell, make it even simpler by not allowing a property to span multiple lines…"

I personally don't like that... look at 11.7 PASOE security config:

OERealm.AuthProvider.multiTenant=false

OERealm.AuthProvider.userDomain=consultingwerk

OERealm.UserDetails.realmURL=internal://nxgas

OERealm.UserDetails.realmClass=Consultingwerk.Web2.SmartFramework.Authentication.SmartHybridRealm

OERealm.UserDetails.grantedAuthorities=ROLE_PSCUser

OERealm.UserDetails.appendRealmError=false

OERealm.UserDetails.propertiesAttrName=

In pretty JSON, this would be a structured document:

{

 OERealm:  {

  AuthProvider: {

    multiTenant: false,

    userDomain: "consultingwerk"

 },

 UserDetails: {

    realmURL: "internal://nxgas",

    realmClass: "Consultingwerk.Web2.SmartFramework.Authentication.SmartHybridRealm",

    grantedAuthorities: "ROLE_PSCUser",

    appendRealmError: false,

    propertiesAttrName: null

 }

}

And those in Praque for the PUG Challenge next week (http://pugchallenge.eu/) should not miss the CCS Birds of a Feather session to talk about participation in this!