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

Support dynamic re-localization of prefs framework components



    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • Prefs Framework, UI Options
    • None


      This requires the changes from the FLUID-6148 line of work, and should likely also wait on the FLUID-6420 work to before implementing.
      Suggestion from Antranig in the [fluid-work channel today|http://irc-logs.fluidproject.org/%23fluid-work/%23fluid-work.2019-12-18.log:]
      Right now there are two ways of using ResourceLoader resources - the "dynamic path" involves referring to them regardless of whether they have loaded, via a model reference or a messageResolver reference, etc.
      And the "static path" involves the pattern that we generally use in UIO since its usage of ResourceLoaders is based on the legacy system, whereby you explicitly wait for the onResourcesLoaded event to fire
      In the static path you simply get the value of the resource as it has loaded and don't get the benefit of any dynamic updates
      So every UIO panel has one of these attached: https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L74
      It gets its "messageBase" via this distribution: https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L82
      Now all of these messageBase values get baked into the component via the AuxBuilder here: https://github.com/amb26/infusion/blob/FLUID-6145/src/framework/preferences/js/AuxBuilder.js#L474
      Although there seems to be some confusion here since it looks like these panels separately inherit directly from the parent bundle via the prefsEditorConnections grade: https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L655
      I think the best thing to do would be to hoist an actual test case demonstrating relocalisation into the core framework, which would then be more than a "demo" : p
      My suspicion that the best way of fixing this is to improve the strategy in the AuxBuilder which implies some core work by Justin_o
      Probably the most direct approach is to create a kind of "dynamic path" cut-through that resolves the root message bundle dynamically and early, and then rewire all the references to bind into that, so that even if the current rendering model makes the components look as if they have to wait for the I/O to finish, they can bind to another component that doesn't
      This involves the least upheaval, I think, and lets us keep our existing clunky "strings" model that the old renderer relies on




            Unassigned Unassigned
            jobara Justin Obara
            0 Vote for this issue
            1 Start watching this issue