I have rewritten the core grade merging algorithm in the framework as per
http://issues.fluidproject.org/browse/FLUID-5085 and
http://issues.fluidproject.org/browse/FLUID-5108 - this thankfully went off with fewer problems than feared
for so fundamental a change, but not unexpectedly did cause a small hiccup in the UIOptions hierarchy -
recent versions of this include a mixin grade "fluid.uiOptions.transformDefaultPanelsOptions" which I think
in itself probably needs a bit of reworking, but in the meantime to work with the new system it required a
change in its grades list from ["fluid.uiOptions.inline", "autoInit"] to ["fluid.viewComponent", "autoInit"]
This is because all the test cases where it is used supply it as a direct option grade which per the new
rules take priority over any builtin grades - from FatPanelUIOptionsTests.js we have
fluid.defaults("fluid.tests.fatPanelIntegration", {
...
components: {
fatPanel: {
type: "fluid.uiOptions.fatPanel",
...
options: {
gradeNames:
["fluid.uiOptions.transformDefaultPanelsOptions"],
where the mixin has grade "fluid.uiOptions.inline" this causes a conflict with the material in
"fluid.uiOptions.fatPanel" itself which has
fluid.defaults("fluid.uiOptions.fatPanel", {
gradeNames: ["fluid.uiOptions.inline", "autoInit"],
...
uiOptionsLoader: {
type: "fluid.uiOptions.fatPanelLoader"
}
The key issue here is the refined type of "uiOptionsLoader" which is required to make all the iframe
injection work correctly. If "fluid.uiOptions.transformDefaultPanelsOptions" is given the grade
"fluid.uiOptions.inline", the effect as used in the test case is to re-override the grade material defining
"uiOptionsLoader" back to the defaults in "fluid.uiOptions.inline" which has this as a plain
"fluid.uiOptions.loader".
There are a few ways to avoid this issue but revising the mixin grade seemed the most straightforward - but
this highlights the care needed to avoid trumping builtin material with high priority dynamic grade
information in the new system. At least the new rules are clear and consistent even if they have now
diverged even further from those operated by type systems from the "object-oriented" mentality.
I left an implementation comment on the mixin grade itself since at the very least it needs a name change,
and really needs some rewriting since right now there is the odd situation that its use only appears in test
case drivers - it should really be folded into the rest of the "starter" grade system.
https://github.com/fluid-project/infusion/pull/390/files
Cheers,
A
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
