Uploaded image for project: 'Fluid Infusion'
  1. Fluid Infusion
  2. FLUID-5835

Deduplication of distributions by namespace destroys extra blocks sharing distribution

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: IoC System
    • Labels:
      None

      Description

      Our fix for FLUID-5824 has too aggressively deduplicated the distributions at target. The failure symptom is in resolving an overridden message bundle in BuilderTests.js - as reported on https://github.com/fluid-project/infusion/pull/654 , the failure is:

      The composite panel should be rendered correctly - at sequence position 1 of 5
      Expected: "increase"
      Result: "[Message string for key increaseHeader not found]"
      Diff:

      The setup here is rather subtle. As a direct override we have, in BuilderTests.js,

          fluid.defaults("fluid.tests.composite.increase", {
              gradeNames: ["fluid.prefs.compositePanel"],
              messageBase: {
                  increaseHeader: "increase"
              },
      

      Then, as a subcomponent override, we have, arising from within the guts of AuxBuilder.js, a definition which results in:

      ....
          components: {
              increasing: {
                  container: "{prefsEditor}.dom.increasing",
                  createOnEvent: "onPrefsEditorMarkupReady",
                  options: {
                      gradeNames: "fluid.prefs.prefsEditorConnections",
                      messageBase: "{messageLoader}.resources.increasing.resourceText"
      

      NOW, what then happens is that we attempt to distribute the "messageBase" property to the panel to the rather awkwardly defined "fake" message bundle named "msgBundle" - from Panels.js:

          fluid.defaults("fluid.prefs.panel", {
              gradeNames: ["fluid.prefs.msgLookup", "fluid.rendererComponent"],
              distributeOptions: {
                  source: "{that}.options.messageBase",
                  target: "{that > msgResolver}.options.messageBase"
              }
      

      What happens here is that the BLOCKS constituting the component's protoOptions pass through FluidIoC.js "filterBlocks", which then gives rise to two blocks sharing the same distribution namespace (in this case the automatically allocated "no-namespace-distribution-mc87fiq-27"). Only one of these survives - the one of record type "subcomponentRecord" which resolves messageBase to undefined, losing the one arising from the defaults override in the test case completely.

      Examining this pathway suggests that the "source" scheme for distributeOptions is really rather rickety and that even after reverting this regression, we can expect many other kinds of failure of this kind to arise over time - JIRAed separately at FLUID-5836

        Attachments

          Activity

            People

            Assignee:
            antranig Antranig Basman
            Reporter:
            antranig Antranig Basman
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: