Using a Config/Properties File for your Application - Forum - OpenEdge Development - Progress Community

Using a Config/Properties File for your Application

 Forum

Using a Config/Properties File for your Application

This question is answered

Good day.

Does anyone use a config or properties file (similar to the .properties files you see in OE)  or anything else to specify configuration data for your application? If so, what approach did you take? XML or JSON data? Text file with a home-grown parser to get keys/values?

Thanks.

Jeff Ledbetter

Roundtable Product Architect

www.roundtable-software.com

Verified Answer
  • 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.

    Jeff Ledbetter

    Roundtable Product Architect

    www.roundtable-software.com

All Replies
  • Nothing beats JSON: Easy to read by man and machine.
    Von: Jeff Ledbetter [mailto:bounce-jeffledbetter@community.progress.com]
    Gesendet: Dienstag, 24. Oktober 2017 14:10
    An: TU.OE.Development@community.progress.com
    Betreff: [Technical Users - OE Development] Using a Config/Properties File for your Application
     
    Update from Progress Community
     

    Good day.

    Does anyone use a config or properties file (similar to the .properties files you see in OE)  or anything else to specify configuration data for your application? If so, what approach did you take? XML or JSON data? Text file with a home-grown parser to get keys/values?

    Thanks.

    View online

     

    You received this notification because you subscribed to the forum.  To stop receiving updates from only this thread, go here.

    Flag this post as spam/abuse.

     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • 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.  

    Jeff Ledbetter

    Roundtable Product Architect

    www.roundtable-software.com

  • Unfortunately, support for INI files is windows-only.

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

    Jeff Ledbetter

    Roundtable Product Architect

    www.roundtable-software.com

  • 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 :)

    What I like most is use a temp-table with write-something and then encrypt the content when saving just to make sure they don’t feel like editing it outside of the app, do provide some properties editor for what the user is allowed to change though.


    Marian Edu

    Acorn IT 
    +40 740 036 212

  • INI works nicely with OE on Windows, and you can use GET-KEY-VALUE and friends. Not on other platforms alas.
     
     
  • 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.

    Scott Augé
    President
    Amduus Information Works, Inc.
    Technical Services for Business and Government
    http://www.amduus.com/cms

  • 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. :)

    Jeff Ledbetter

    Roundtable Product Architect

    www.roundtable-software.com

  • 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. :)

    Jeff Ledbetter

    Roundtable Product Architect

    www.roundtable-software.com

  • 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…

    prop1=value1
    prop2=value2

    Then just use import from, read each line (skip if starts with some comment // or #) then everything before equal is name and value follows till end of line

    Works on any os so why not making it yours ;)

    Marian Edu

    Acorn IT 
    +40 740 036 212

  • 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.

    Jeff Ledbetter

    Roundtable Product Architect

    www.roundtable-software.com

  • "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

     }

    }

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Part of the challenge is knowing how to store the (config) data. Part is exposing that data to the application – and doing it in such a way that the property ‘storage’ is pluggable and replacable. The CCS Steering Committee received a proposal for a Property/Config manager  (https://github.com/progress/CCS/blob/master/Proposals/V1/CCS-Proposal-ConfigMgr-1.0.pdf ) that’s currently “parked” subject to finding a team to spec it out. Maybe this is the time to form one, since it’s in your interest now?