Since long qooxdoo supported the idea of a set of global values that can be queried from different parts of an application. Among other things, this was used in the framework to add debug code in the form of additional tests and logging, to provide browser-specific implementations of certain methods, asf. You can think of this set as a global key:value store for the application. Values were write-once, read-many. There were keys that came pre-defined with qooxdoo, and others that could be defined by the application itself. Values for those keys could only be provided at application startup, and not changed later.
So far, we had two separate buckets for global values: One with just plain values, called Settings. Settings were used to simply feed key:value pairs into an application.
The other were Variants. From the application coding side, they were like settings. During an application run, each had a single, well-defined value, which the programmer could query through various functions. Like with settings you could feed a value for a variant key through the Json config, the index.html or an URL parameter to the application. Unlike settings, though, variants had special consequences on the tooling side of qooxdoo:
- You could specify more than one value in the Json config; this would result in multiple application files being generated for the build version of the app, one for each value. (This was particular popular for creating browser-specific builds, e.g. one for mshtml, one for gecko, one for webkit asf.). If multiple variants had more than one value, the generator would produce an application for each combination of the possible values of those variant keys.
- During the creation of a single of those potentially many applications, the generator would remove code that did not apply to the variant value currently in effect. This meant a lot of code, e.g. for debug handling, could be removed for the optimized build.
The new word – Environment
With the upcoming 1.4 release of qooxdoo we will have a concept that embraces setting, variants, and a third source of global values for an application: values typically detected at run time, like the current JS engine, the browser version, or supported features like HTML5 web workers or data: URLs. Those had previously a completely different API in the qx.bom.client.* name space, with sometimes inhomogeneous ways to get at various bits of information.
All those values the application can draw from are now put together in something we called the environment of the application, with a single API. (In programming language semantics, the “environment” is often the term to refer to the set of bindings that are in effect when a certain piece of code is executed). The new API is qx.core.Environment, and its main methods to query key values are qx.core.Environment.select() and qx.core.Environment.get(). qx.core.Environment.select is a straight port of qx.core.Variant.select. It takes a key string and a map, and returns the map value which key matches the current value of the key string passed as the first parameter.
qx.core.Environment.get() is a simple getter, which takes the key string as a parameter and returns the current value, if any. This can be used, among other things, in condition expression where you previously might have used qx.core.Variant.isSet(). And like with qx.core.Variant.isSet(), those calls will be optimized if the call to qx.core.Environment.get() is the only expression in the condition, or is part of a simple comparison (
!==) with a literal value. So you get basically the same code optimizations as with qx.core.Variant.isSet().
Settings and variants are continued to be supported in the upcoming release, so there is no need to rush. But you will get appropriate deprecation warnings when using the old qx.core.Settings and qx.core.Variant APIs.