Hi Antranig, Seeking your advice...
Github branch: https://github.com/cindyli/infusion/tree/FLUID-4234 As you know, the UI Options controls template has been split into 4 templates: the top parent template that has DIVs for title, button, preview and 3 placeholder DIVs for 3 sub-templates that each corresponds to one section of controls. The 4 templates map to 4 components: top template maps to view component "fluid.uiOptions" and 3 sub-templates map to 3 sub renderer components of "fluid.uiOptions" - "textControls", "layoutControls", "linksControls". A problem was since detected by tests (src/webapp/tests/component-tests/uiOptions/html/UIOptions-test.html) due to the asynchronous template loading. The errors in the type below were reported at calling refreshView() in each renderer components: * Error during rendering - component with id textSize which has a queued decorator was not found in the output markup etc. With Yura's help, we implemented the idea of URL expander that Yura has been using in CSpace to resolve the similar issue. As I understand, the purpose of URL expander is to inform framework the correct location of all the templates at the instantiation of fluid.UIOptions to make the use of fetchResources option "amalgamateClasses" possible. The code in detail: https://github.com/cindyli/infusion/blob/FLUID-4234/src/webapp/components/uiOptions/js/UIOptions.js#L384 https://github.com/cindyli/infusion/blob/FLUID-4234/src/webapp/components/uiOptions/js/UIOptions.js#L174-213 This implementation did solve the issue, however, it has a flaw that the implementers now have to specify the template location via urlExpander. The "resources" defaults are no longer usable. What I meant in code: https://github.com/cindyli/infusion/blob/FLUID-4234/src/webapp/tests/component-tests/uiOptions/js/UIOptionsTests.js#L82-89 Michelle and I were talking about this and feel this flaw is unacceptable. Do you have an idea how to tackle this flaw or any new solution? Next, I will be trying with Yura's another suggestion that is to re-construct each renderer component a view component with a sub-renderer component and call fetchResource() in the parent view component. I am in doubt if this would help with the asynchronous loading since right now refreshView() is already called in the callback function of fetchResource(), even though in the renderer component itself. Thanks. And many thanks to Yura who has been super helpful during my struggling with UI Options. :) Cindy _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
