Answers to questions from Mike Skirpan

[Antranig Basman]

At his blog at https://github.com/wannabeCitizen/data-dashboard/blob/master/docs/journal/06-15-2016.md our 
GSoC student Mike Skirpan has asked some chartAuthoring and Infusion-related questions which I will answer 
inline here:

> Registering the component's namespace. When to use it? [eg, https://github.com/fluid-project/chartAuthoring/blob/master/src/js/transformations.js ].
> It seems like it is mostly useful for creating simple helper-type components that aren't part of your main component tree.

Yes, that's correct. A call to "fluid.defaults" automatically registers the namespace of the component - 
that is, it creates a function object with that global name, and creates all the parent objects necessary to 
house it. You only need an explicit call to registerNamespace when
i) You have a helper function whose immediate parent name has not already been registered in the global 
namespace tree
OR
ii) You want to get access to an existing registration in an infusion system that is not visible in your own 
JavaScript global object (this is primarily useful in node.js applications which insulate the global objects 
visible in different files from one another)

> Use of "container" a lot without css ref, but some kind of IoC ref.
 > EG, https://github.com/fluid-project/chartAuthoring/blob/master/src/js/transformations.js] How should
> one usethis keyword in infusion?
 > Does it automatically refer to the container div of the given component; if so, where are you meant to 
specify it?

I guess you meant a site like: 
https://github.com/fluid-project/chartAuthoring/blob/master/src/js/chartAuthoring.js#L76 - this shows 
setting up the selector/element from which the container of a viewComponent will be constructed. On 
construction, the actually resolved container is assigned to that.container as a jQuery element - it can 
then be referred to by configuration or code like any other member, e.g. 
https://github.com/fluid-project/chartAuthoring/blob/master/src/js/pie.js#L211

See references to the role of the container at http://docs.fluidproject.org/infusion/development/DOMBinder.html

> Would highly recommend a full example at bottom, here: http://docs.fluidproject.org/infusion/development/UnderstandingInfusionComponents.html

Yes, absolutely

> So styles for a ViewComponent is only used as a sort of documentation tool?

Essentially, yes - there is no code in the framework which depends on or operates this - it is a convention 
between users and implementors of the component. A similar convention is the use of a block named "markup" 
to hold short-ish HTML template strings which might be passed in to fluid.stringTemplate before being slung 
into the DOM via $()

> ? Example of crucial documentation that's confusing? --> "Note that as a result of growing power in the
> IoC framework toperform most actions "in place" with respect to an existing component in its original
 > location without having to inject it elsewhere."

Agreed - highly confusing as well as being ungrammatical. It could better read something like "In many 
cases, you will not need to inject components elsewhere in the tree since they can be effectively used in 
their original position by means of IoC references (for reading) or options distributions (for modifying)".

Often you will inject components *down* the tree in order to have handy (and substitutable) references to 
them via shorter paths, or inject them *up* the tree in order to promote a component to higher visibility 
that is part of the implementation of some other assembly (the latter is rare)

> Renderer vs. View components -- which should I be using? I feel like I remember hearing that you're phasing
 > out renderer components?

Yes, that's right. The renderer is still available for the intrepid, but in general we recommend the use of 
simple schemes like string templating (as via fluid.stringTemplate mentioned above), or slightly more 
complex libraries like handlebars, together with something like https://github.com/GPII/gpii-binder/pull/1 
for data binding - I note that chartAuthoring has its own "micro-binding" framework at 
https://github.com/fluid-project/chartAuthoring/blob/master/src/js/valueBinding.js

> This is a bad set of examples: http://docs.fluidproject.org/infusion/development/SubcomponentDeclaration.html#injected-subcomponent-declaration

Yes, they are terrible - much of the material isn't even relevant, as well as being inadequately explained.

> Do you recommend using dynamic components for the Fields Component in the Data Dashboard spec?

Yes, they are a stable and indispensable facility, even they are still a little clunky to use. The "far 
future" framework will allow us to image components into existence and nonexistence by a model-relay-like 
facility.

> Can't find good info on templates... templateLoader

We had a Skype chat with Cindy and confirmed that this was an implementation detail of the prefs framework 
that had "accidentally" leaked into public use. This should be split out into a self-contained file and 
documented properly. In our call we traced through the implementation workflow involving the deprecated 
fluid.fetchResources in 
https://github.com/fluid-project/infusion/blob/master/src/framework/core/js/FluidRequests.js#L53 and the 
chartAuthoring https://github.com/fluid-project/chartAuthoring/blob/master/src/js/templateInjection.js 
implementation

> In the chartAuthoring demo component, how does initialData get taken from the demo component and
 > rendered? Can't follow this trail and its crucial to understanding everything...

In our Skype chat and the following discussion on IRC 
https://botbot.me/freenode/fluid-tech/2016-06-16/?msg=68049015&page=1 we established that the chartAuthoring 
component's workflow this is currently rather wacky, in that it reuses in the demo what should be an 
implementation detail of the dataEntry component in order to round-trip the model data through the DOM in 
order to get it into the model. That is,
https://github.com/fluid-project/chartAuthoring/blob/master/src/js/chartAuthoring.js#L279 loads the data 
into the entry UI from where the data binding facilities in 
https://github.com/fluid-project/chartAuthoring/blob/master/src/js/valueBinding.js fish it back out into the 
dataEntry component's model. We agreed that this should be refactored in chartAuthoring but this will take a 
little while (need to get Alan's big pull in first). You're free to try using the component's changeApplier 
directly to update its model - if you run into any problems, we will straighten them out.

Thanks for this excellent set of questions and observations - this is code that we're keen to make highly 
usable and greatly appreciate anything which might flatten out the learning curve for others. Looking 
forward to developments -

Cheers,

Antranig