FLUID-5067: Ability to index options content of grades, and issue queries returning all registered grades matching a pattern

Description

This use case emerged in two separate cases in the current UIOptions schema work (FLUID-4907). Firstly, it is necessary to be able to look up concrete grades (schemas, enactors and panels - the 3 "ant types") that handle a particular "common options grade" - for example, (current draft, may change: ) in the following schema grade:

fluid.defaults("fluid.uiOptions.schema.textSizer", {
gradeNames: ["fluid.uiOptions.schema"],
schema: {
"fluid.uiOptions.textSizer": { // common grade name
"type": "number",
"default": 1,
"min": 1,
"max": 2,
"divisibleBy": 0.1
}
}
});

and the following panel grade:

fluid.defaults("fluid.uiOptions.linksControls", {
gradeNames: ["fluid.uiOptions.settingsPanel", "autoInit"],
preferenceMap: {
links: "fluid.uiOptions.emphasizeLinks",
inputsLarger: "fluid.uiOptions.inputsLarger"
}, <= HERE we use "common grade names"
.....etc.

Respectively, we may want to look up in the system, the overall grade "fluid.uiOptions.schema.textSizer" from the common grade "fluid.uiOptions.textSizer", or the panel grade "fluid.uiOptions.linksControls" from either of the common grade "fluid.uiOptions.emphasizeLinks" or "fluid.uiOptions.inputsLarger".

The second use case emerged from the requirement for the "default auxiliary schema". In talking of the WordPress integration, anastasia mentioned that it would be useful for the videoPlayer code, and the uiOptions code separately, to cooperate by the videoPlayer being able to register certain grades representing UIO panels, and in the absence of any further action from the UIO user, for these to be picked up in the generated UIO interface. Given our future model for UIO building is to be schema-driven, this seems to translate into a requirement for a "default auxiliary schema" which is assembled through a kind of query for all grades of a particular kind in the system (e.g. panels, etc.). This was the kind of problem which we would formerly have dealt with through the use of demands blocks. Demands blocks are an odd fit here since it is not clear what the "context" is - they would be being used purely for the FLUID-4392-style additivity for options targetted at a particular name. This also implies that the target name (e.g. "fluid.uiOptions.defaultAuxiliarySchema") is known to the originating code. The facility described here allows for the possibility of a "pull" model rather than a "push" model for aggregation. This is familiar from other environments such as Spring with facilities like "beanNamesForType" etc.

Initially it seemed reasonable just to be able to query for "all grades with a particular supergrade" but the examples above show the requirement to be able to index any arbitrarily nested strings in the default model - this will need to be done with dedicated functions which "digest" the options into the index keys

Comments

• Justin Obara commented 2013-09-13T15:54:58.943-0400

  Pull request ( https://github.com/fluid-project/infusion/pull/352 ) merged into the project repo at 5cd0ac50dd9ac2a76314fc4cb43fdc2a42ae277b