Additional Infusion questions

Antranig Basman antranig.basman at
Thu Aug 31 23:01:54 UTC 2017

Cheers for these good questions, Danail.

For the first question(s), we generally favour having markup in its own file when i) there are more than a 
couple of tags involved, ii) the markup may be worked on by different teams with different skills, iii) 
there seems to be some reuse potential for the markup/component at different sites in an application or an 
overall architecture.

Your approach in the code snippet you have pasted looks good. In practice, you will want to consolidate all 
resource loading into a single component at the top of the component tree, in order to avoid multiple 
fetches for the same template. Compare with the way that an Infusion "prefsEditor" is held within a tree 
rooted at a "prefsEditorLoader":

You will want to split up responsibility for loading from responsibility for injecting the markup - but this 
will happen naturally as you build a larger design which renders multiple widgets.

Other comments on the code -

i) You have a race on lines 22 between the different listeners to the "onResourcesLoaded" event - the 
ordering of JSON keys can't be depended on to be stable, and so the sequencing right now is just happening 
by accident. You can add at line 24 an annotation

priority: "before:render"

to ensure that the sequence will always be as you want.

ii) There's a problem with the model binding of the dropdown component. Although it would be nice if 
expressions like "${{dropDown}.model.selection}" established the appropriate bi-directional linkage (there's 
no reason why this couldn't be the case), in practice the renderer is too dim. Fully-qualified IoC 
references like this as they appear in renderer trees are read-only. You'll instead need to write here, 
"${selection}" - the renderer is only intelligent enough to set up synchronisation with a component's own 
model. You can then get rid of the event binding at line 47 (as well as the onOptionChanged event) and 
replace it with an implicit model relay between the component models - e.g. on line 47 you will instead write

model: {
     selection: "{dropDown}.model.selection"

You can then respond to any changes at the top-level model by writing the listener there - e.g.

modelListeners: {
     "": "{that}.events.doSomething"...

ii) a) expanding on what this will require in your full design - when "dropDownHolder" is some kind of 
dynamic component, the model relay will itself have to be dynamic. There is some limited scope for direct 
dynamism in a relay definition - for example, you can arrange for a single path segment element to be 
interpolated by an IoC reference as in

however, I imagine you will want more free-form dynamism than this since you will want to bind each widget's 
update directly onto the root model holding the user's preference set. This is what these rather cumbersome 
and hard-wired pieces of code in the preferences framework achieve here -
and here

but instead I recommend you use a more modern approach and synthesise the model relay options at the point 
you generate the dynamic component. This implies that you will need to hide all the "static" configuration 
for the holder component in its grade list, and write a definition like this:

This approach allows you total dynamic control over the dynamic component's options. In this case you would 
arrange, e.g. that arguments.0 holds something like
     type: "",
     model: {
         selection: "{rootModelHolder}.model.<any path you like here>"

You can see another example of this approach here:
and here

it seems to arise quite regularly than a certain kind of Infusion application centres itself around a 
certain "heart of dynamism" where a component of an essentially arbitrary type and configuration gets 
constructed, and yours is clearly one of this kind.

Good luck and I look forward to talking with you more about your design tomorrow. Unforunately I've burned 
through all the time I might have used to work on the rendering sample for you, but it looks like you're 
making progress in the right direction with your own sample already.



On 31/08/2017 16:44, Danail Dimitrov wrote:
> *
> Hi everyone,
> As it was mentioned on the Architecture meeting yesterday, we've been engaged in adding multiple components, 
> based on an array input with unknown length - a list of user settings' metadata. Every setting specifies 
> which adjuster (widget) to be used for it. There are a few more questions we'd like to ask your opinion 
> about in addition to what we discussed today.
> Firstly, as the PCP is not aware of the number and type of the adjusters (the same adjuster may appear 
> multiple times) which are to be shown, a static approach seems to not be applicable for us. Having that in 
> mind, we expect our components (adjusters) to have their own template (markup) which is to be injected with 
> their initialization. Does this make sense?
> We'd also like to know what convention you follow for keeping such markups. When do you favor using inline 
> definition like in
> versus using an external file?
> On a similar note, keeping related markup in an external file (an `.html` file) led to another question: 
> What is the proper way of loading the markup and injecting it within a given container? We followed the 
> example supplied here - 
> <>- but 
> we're not sure if this is the best way of accomplishing this. Here's a draft of our idea - 
> Are we on the right path?
> Any comments would be helpful!
> 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
> To unsubscribe, change settings or access archives,
> see

More information about the fluid-work mailing list