CODEWITHSUNDEEP
javascriptqooxdoo
Martin Schmidt
Martin Schmidt

Reputation: 189

Best practices for passing configuration to a qooxdoo app

A complex qooxdoo (desktop) application may need to obtain deployment-specific configuration at startup, for example:

and so on. At the moment, we do the following:

<head>
    <script type="text/javascript">
        config = {
            key1: "foo",
            key2: "bar",
            key3: "<%= getParameter("myapp.key3") %>"
        };
    </script>
    <script type="text/javascript" src="script/myapp.js"></script>
</head>

As you've noticed, it's a JSP that provides dynamic config.key3, along with static config.key1 and config.key2. I somewhat dislike this approach because 1) config top-level object is not recognized in qooxdoo application code, and this results in compiler warning, 2) you can accidentally mess up with another top-level object of same name. Can anyone suggest any better, cleaner way to do the same? It's important that a combination of static and dynamic configuration is supported. For example, a developer hardcodes his specific config into some VCS-ignored JSON file; production environment serves config data from the database; staging/QA environment can use both sources for different parts of config.

The problem is not limited to qooxdoo, of course. I think this may as well be topical for any standalone JavaScript application that may need deployment-specific customization.

Upvotes: 1

Views: 290

Answers (2)

saaj
saaj

Reputation: 25204

For pre-defined environments I suggest to use normal Qooxdoo configuration, not the hack @geonik presented. Here follows excerpt from normal config.json:

"config-warnings" : 
{
  "job-shadowing" : ["common", "source-script", "build-script"]
},

"jobs" :
{

  "common" :
  {
    "environment" :
    {
      "appname.version"     : "1.0.0",
      "appname.timeout"     : 30000,
      "appname.analyticsId" : "UA..."
    }
  },

  "source-script" :
  {
    "environment" :
    {
      "appname.serviceUrl"  : "http://127.0.0.1:8080/service",
      "appname.crossDomain" : true
    }
  },

  "build-script" :
  {
    "environment" :
    {
      "appname.serviceUrl"  : "/service",
      "appname.crossDomain" : false
    }
  }

}

With the above you have one settings in development build and other settings in production build. You can add more environments, like QA. with other desired settings. Then access them with normal qx.core.Environment.get.

I don't suggest to mix runtime settings with Qooxdoo configuration which is inherently static. Just load them on application start with any qx.io.* way and handle in your classes.

Upvotes: 1

geonik
geonik

Reputation: 181

Use below method to solve both problems (warning and top level object):

a. in index.html before loading your application's JS:

window.qx = { $$environment: {
    "myapp.key1": "foo"
} };

b. later in your Qooxdoo application

var key1 = qx.core.Environment.get("myapp.key1");

Upvotes: 2

Related Questions