将配置传递给qooxdoo应用程序的最佳实践
[英]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: 
复杂的qooxdoo（桌面）应用程序可能需要在启动时获取特定于部署的配置，例如：
- REST/WebSocket backend URL (which may be different from script/document location); REST / WebSocket后端URL（可能与脚本/文档位置不同）;
- branding data; 品牌数据;
- enabled/disabled features; 启用/禁用功能;
- performance tweaks 性能调整
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 . 正如您所注意到的，它是一个提供动态config.key3的JSP，以及静态config.key1和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. 我有点不喜欢这种方法，因为1）在qooxdoo应用程序代码中无法识别config顶级对象，这会导致编译器警告，2）您可能会意外地弄乱另一个同名的顶级对象。 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; 例如，开发人员将其特定配置硬编码为某些VCS忽略的JSON文件; production environment serves config data from the database; 生产环境提供来自数据库的配置数据; staging/QA environment can use both sources for different parts of config. staging / QA环境可以将两个源用于配置的不同部分。
The problem is not limited to qooxdoo, of course. 当然，问题不仅限于qooxdoo。 I think this may as well be topical for any standalone JavaScript application that may need deployment-specific customization. 我认为这可能是任何可能需要特定于部署的自定义的独立JavaScript应用程序的主题。
2 个解决方案
解决方案1
2 已采纳 2015-02-24 20:25:59
Use below method to solve both problems (warning and top level object): 使用以下方法解决这两个问题（警告和顶级对象）：
a. 一种。 in index.html before loading your application's JS: 在加载应用程序的JS之前的index.html中：
window.qx = { $$environment: {
"myapp.key1": "foo"
} };
b. 湾 later in your Qooxdoo application 稍后在您的Qooxdoo应用程序中
var key1 = qx.core.Environment.get("myapp.key1");
解决方案2
1 2015-02-25 10:54:21
For pre-defined environments I suggest to use normal Qooxdoo configuration, not the hack @geonik presented. 对于预定义的环境，我建议使用正常的Qooxdoo配置，而不是提供的黑客@geonik。 Here follows excerpt from normal config.json : 以下是正常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. 您可以添加更多环境，例如QA。 with other desired settings. 与其他所需的设置。 Then access them with normal qx.core.Environment.get . 然后使用普通的qx.core.Environment.get访问它们。
I don't suggest to mix runtime settings with Qooxdoo configuration which is inherently static. 我不建议将运行时设置与本质上是静态的Qooxdoo配置混合使用。 Just load them on application start with any qx.io.* way and handle in your classes. 只需在应用程序启动时使用任何qx.io.*方式加载它们并在您的类中处理。
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.