On 07/11/11 18:03, thron7 wrote:
>
>
> On 11/07/2011 05:37 PM, Henrik Pauli wrote:
>> Back to my config issues :)
>>
>> I've been trying to tackle the following problem:
>>
>> There's a production system and some development systems, which differ
>> in particular in URLs. For example the RPC is behind a different URL,
>> and so is for example UploadMgr's server-side handler.
>>
>> I'd like to have as few as possible occurrences of these URLs in the
>> source, and it would be especially nice if it were a separate config
>> file slurped up during generation time. Optional bonus points if the
>> same config file can be used everywhere, but depending on eg. the system
>> hostname, something different happens :)
>>
>> So far, I read that it's possible to include an external JSON file into
>> the config, and I guess it could have some custom environment keys
>> defined for the application to use. Does anyone have any suggestions,
>> recommendations, corrections? I do kinda feel disoriented with this.
>
> I think you're on the right track, use custom environment keys. E.g. in
> your config.json you can have
>
> {
> "name" : ...,
> "include" : [
> { "path" : "server_settings.json" },
> ...
>
> and in server_settings.json you have
>
> {
> "jobs" : {
> "server-settings" : {
> "environment" : {
> "myuplodmgr" : "http://.....";
> }
>
>
> Now back in your config.json you have to use the new "server-settings"
> job, to inject its settings. E.g.
>
> {
> ...
> "jobs" : {
> "source-script" : {
> "extend" : ["server-settings"]
> },
> "build-script" : {
> "extend" : ["server-settings"]
> }
>
> This will make sure your environment settings are used when creating the
> app in source and build version.
Thanks, that's indeed pretty much what was forming in my head.
I suspect that the creation of this pseudo-job is needed because
"environment" is a job-specific key, and not possible to set globally?
And I guess to get the value defined in the config, I'll use
qx.core.Environment.get("blah").
> It will not be that straight-forward to integrate site-specific
> settings, but you can use macros for that. Let's suppose the uploadmgr
> URL just differs in the name of the server, you could do in
> server_settings.json
>
> {
> ...
> "let" : {
> UPLOADMGR_SERVER : "<some default server name>"
> },
> "jobs" : {
> "server-settings" : {
> "environment" : {
> "myuploadmgr" : "http://${UPLOADMGR_SERVER}/path/to/handler";
> }
> }
>
> and then pass a suitable binding for the macro on the development
> machine when invoking the generator, like
>
> generate.py -m UPLOAD_SERVER:server1.mydom.ain source
>
> Of course you could maintain those macro bindings in yet another config
> file which would be machine-specific. Automatic evaluation of the host
> name is not possible currently (though support of OS environment keys is
> in the making :).
Hmmm, that's a bit clumsy, in the sense that I'd like to avoid the
possibility of forgetting to specify something on the command line.
I suddenly had an idea to get around the lack of conditionals in JSON
with simply doing the heavy lifting inside a Singleton (that is, it
would know the paths and set its public properties according to the
environment), but that might not be a good solution either -- although
one that might start to work great once OS environment keys can be
accessed. This came up because I already do have a Singleton that holds
some data during the run of the application, so it's already used all
over the place in the code -- it wouldn't actually be more trouble to
add more props to it.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
