Fwd: Infusion questions

Antranig Basman antranig.basman at colorado.edu
Wed Aug 30 12:57:03 UTC 2017

Thanks for these questions Georgi - we'll try to discuss this a bit further with Justin later today but here 
are some answers to these specific questions.
The Infusion renderer has been deprecated for a while, since it was designed some time ago in a rather 
different technological environment and it has some significant limitations. However, there is still a fair 
amount of use of it in the codebase, and it hasn't yet been replaced with a single preferred approach.

In terms of your Approach 1, there are a couple of problems - firstly, the renderer does not naturally 
recurse through child components when accumulating protoTrees - the renderer predates the Infusion component 
system and expects the renderer prototree to be returned complete in a single pass. You can either do this 
iteration yourself by querying your child components on startup (e.g. with fluid.queryIoCSelector) or by 
distributing a listener down to your children which they all notify when they are created.
Secondly, the renderer doesn't permit two components to share the same id - in this case "controlName". To 
repeat a component it is necessary to emit an id with a colon, e.g. controlName:1 etc. which is something 
that the repetition expander will do for you automatically.

In terms of Approach 2, this is close to working - there are a few points which have slipped -
i) the selectors which relate to repeating material need to be registered in "repeatingSelectors" in the 
rendererComponent's options
ii) there is a missing layer of quoting in the repeated component tree - it should read 
"${{controlItemInfo}}" rather than just "${controlItemInfo}" (you could probably have written valuebinding 
rather than value with just the one level of quoting, but I haven't tested this), and
iii) the repeatID needs to match the selector name of "controlItem"
iv) since you have no extra level of containment in your markup, the repeating tree needs to consist simply 
of a leaf component (UIBound) itself, and so its key should be "value" rather than "controlId" -
compare with the example in the docs at 

Adjusting your component defaults to read as follows:

     fluid.defaults("gpii.app.settings.controls", {
         gradeNames: ["fluid.rendererComponent"],
         model: {
             controlItems: [
                 "Setting One",
                 "Setting Two",
                 "Setting Three"
         selectors: {
             controlItem: ".flc-controlItem"
         repeatingSelectors: ["controlItem"],
         protoTree: {
             expander: {
                 type: "fluid.renderer.repeat",
                 repeatID: "controlItem",
                 controlledBy: "controlItems",
                 pathAs: "controlItemInfo",
                 tree: {
                     value: "${{controlItemInfo}}"
         renderOnInit: true

will let it work.

Although the renderer is pretty cumbersome to use, it might be helpful to be able to share code with the 
"adjusters" already written as part of the preferences framework, as for example seen in "UIOptions" or the 
browser plugin which Justin Obara is currently working on for the APCP, named "UIO+". So it might be worth 
trying to make this approach work, together with the use of the template fetching scheme that we currently 
use in UIO - let's talk further today.



On 29/08/2017 15:07, Georgi Todorov wrote:
> Hi everyone,
> As you know, we have currently focused on visual tasks until the changes to the PCP API are finalized. We 
> were wondering what would be the best way (in terms of Infusion) to display the user’s settings in the PCP 
> window. Below you can find the two approaches with which we experimented along with some questions about 
> them. Please let us know which of them is better or if we should use something else. Any other comments or 
> suggestions will also be greatly appreciated.
> Approach 1: Using rendererComponents and dynamic subcomponents
> Branch url: https://github.com/danailbd/gpii-app/tree/poc/dynamicSubcomponent 
> <https://github.com/danailbd/gpii-app/tree/poc/dynamicSubcomponent>
> HTML file url: https://github.com/danailbd/gpii-app/blob/poc/dynamicSubcomponent/src/html/settings.html 
> <https://github.com/danailbd/gpii-app/blob/poc/dynamicSubcomponent/src/html/settings.html>
> JavaScript file url: https://github.com/danailbd/gpii-app/blob/poc/dynamicSubcomponent/src/settings.js 
> <https://github.com/danailbd/gpii-app/blob/poc/dynamicSubcomponent/src/settings.js>
> Description: Our idea was to have a viewComponent(gpii.app.settings.mainWindow) which will have several 
> dynamic subcomponents. Each of them will be a rendererComponentrepresenting a single user setting. For 
> reference, please refer to HTML and JavaScript files whose links are provided above.
> Problem: As you can see, there are 3 settings to be displayed (defined in the 
> gpii.app.settings.controlscomponent). However, only the last setting is shown to the user even though a 
> total of 3 dynamic subcomponents are created and rendered. Do we need to place some additional markup or 
> provide other options to the components’ configurations?
> Approach 2: Using rendererComponent with a repeat expander
> Branch url: https://github.com/danailbd/gpii-app/tree/poc/repeatExpander 
> <https://github.com/danailbd/gpii-app/tree/poc/repeatExpander>
> HTML file url: https://github.com/danailbd/gpii-app/blob/poc/repeatExpander/src/html/settings.html 
> <https://github.com/danailbd/gpii-app/blob/poc/repeatExpander/src/html/settings.html>
> JavaScript file url: https://github.com/danailbd/gpii-app/blob/poc/repeatExpander/src/settings.js 
> <https://github.com/danailbd/gpii-app/blob/poc/repeatExpander/src/settings.js>
> Description: The idea here was to have a single rendererComponentwhich will use a 
> fluid.renderer.repeatexpander to generate the markup for all of the user’s settings.
> Problem: Nothing is shown in the browser window. Upon inspection of the DOM tree, one can see that the 
> element whose class is flc-controlItemis not present at all. What else do we need to specify in the 
> components’ configurations or in the HTML in order for the expander to produce the expected results? Does 
> using an expander make sense in this case as each individual setting can be a complicated unit which may 
> require to have a separate Infusion component for itself?
> And one more thing - where can we post such questions (which include code snippets or links to code) in the 
> future?
> Best regards,
> The Astea Team
> /The information in this e-mail and any accompanying files is intended only for the recipients named above. 
> This message may contain CONFIDENTIAL INFORMATION THAT IS LEGALLY PRIVILEGED. If you are not an intended 
> recipient, you may not download, copy, disseminate, distribute or use in any way the information in this 
> e-mail. Any of these actions can be a criminal offense. If you have received this e-mail in error, please 
> notify *Astea Solutions AD*immediately by reply e-mail, and delete this e-mail and any copies of it./
> _______________________________________________________
> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

More information about the fluid-work mailing list