Rethink feature detection class (BZ#4641)

[qx-bug-importer]

Martin Wittemann (@wittemann) wrote:

The current implementation of our feature detection is very monolithic which means, is in one single class. The growing number of features we ant to detect demands a rethink of the current structure. We should also think about async tests for example and all the mobile stuff, which could also nee the detection.

assigned to Martin Wittemann (@wittemann)

[qx-bug-importer]

Tino Butz (@tjbutz) wrote:

Just an idea:

Would be nice to concatenate the feature, e.g.:

Feature.has("iphone&phoneGap.featureX")

would call first the iphone check and than call the "phoneGap" check function:

this["phoneGap"].supported()

PhoneGap.supported : function { return window.PhoneGap != null }

and than the function

this["phoneGap"]["featureX"]()

PhoneGap.featureX = function() { return window.PhoneGap.featureX != null; }

We could save the single results + the whole result in a Map and return the result the next time.

We could use Classes (or Mixins?) for the different feature categories and register the feature tests in the defer. Custom feature tests could be added like this as well.

Feature.add("phoneGap", PhoneGap);

These feature strings could be used as variants as well. The generator could optimize the code, by removing the blog or translating the feature strings to javascript code. Feature checks that never were used could than be removed by the static analysis.

[qx-bug-importer]

Tino Butz (@tjbutz) wrote:

So for me there is no difference between (browser)feature / browser / runtime / extension / device whatsoever. These are all checks that will return a boolean - why not merging it all together into one clear system.

[qx-bug-importer]

Martin Wittemann (@wittemann) wrote:

Here are some things we need to consider:

• Split up detection in separate files
• Find a way to exclude code for specific features (feature based builds)
• Handle asynchronous detection of features
• Execute the detection test on demand
• Cache already detected features
• Add a way to invalidate the cache in case a feature could be reloaded
• Find a way to include the classes implementing feature detection on demand (without #require)
• combine detection for features, browsers, engine
• Handle detections having a value like browser version e.g.
• Merge with variants
• Merge with settings
• Detections should not use much infrastructure (bootstrap classes at most)

[qx-bug-importer]

Martin Wittemann (@wittemann) wrote:

Just committed the move from static properties for separate method checks using a dedicated class. Still got to change settings and variants.

~ r25445-r25489

[qx-bug-importer]

Martin Wittemann (@wittemann) wrote:

* BZ#3097 has been marked as a duplicate of this bug. *

[qx-bug-importer]

Tino Butz (@tjbutz) wrote:

* BZ#4484 has been marked as a duplicate of this bug. *

[qx-bug-importer]

Martin Wittemann (@wittemann) wrote:

Finally moved all variants in the framework and the apps to the environment class. Also added deprecation warnings to all public methods of qx.core.Variant.

trunk: r25994 - r26013

Still missing, a manual page and the class comment of qx.core.Environment.

[qx-bug-importer]

Martin Wittemann (@wittemann) wrote:

Class comment and manual page has been added meanwhile. Therefore, I mark that bug as fixed.